On Sat, 27 Dec 2003, Paul Jarc wrote:
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?
If there are no unseen messages, then the [UNSEEN n] response would be
omitted.
Right now, my greeting looks like * OK
The messages that you report indicate that the client never logged in.
Perhaps your cell phone doesn't know how to do secure (SSL or TLS
encrypted) connections, and wants to send the password in the clear?
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party
On Wed, 17 Dec 2003, Philip Guenther wrote:
Wow. An internal session---perhaps real, perhaps nominal---open to each
mailbox, *just* to avoid having to implement part of the protocol that
you don't like. There are other bits in the RFC that I found tough to
get right; you're telling me now
On Wed, 17 Dec 2003, Christof Drescher wrote:
a) What professional mail server system today relies on any CLIENT
checking for spam/viruses? Even if so, how on earth can one assume that ALL
clients connecting do the proper virus checking.
There are multiple levels of spam and virus checking.
On Wed, 17 Dec 2003, Arnt Gulbrandsen wrote:
Christof Drescher writes:
Anyway: Do you argue such an extension would not be wise to have?
There have been a great many attempts at this, all failed. I do not feel
competent to judge why they failed, and how it can successfully be done.
I can
On Wed, 17 Dec 2003, Christof Drescher wrote:
I think I don't confuse anything about this issue. We were talking about the
pro and cons of Mark's idea of RECENT update, and came about his example,
which I questioned. I did not question IMAP specs or anything, and I did not
bring up the
On Wed, 17 Dec 2003, Christof Drescher wrote:
One addition would then be the part of an extension: A command to supply a
list of folders which it wants to receive untagged STATUS updates about.
Wouldn't that be a really simple solution? Conforming? Rather easy to
implement on both client and
On Wed, 17 Dec 2003, Christof Drescher wrote:
Is a server broken in any way if it sends untagged STATUS updates at its
desire?
No.
b)
Which of these cases can happen if a Recent message arrives, if more than
one session has a mailbox selected:
- none gets a RECENT update
- only one gets a
On Wed, 17 Dec 2003, Christof Drescher wrote:
So what? A server for which it is expensive to do this status update -
don't advertise it in your CAPABILITY and you need not bother coding it.
Right? Even if you advertise it and for a certain folder it is to expensive,
give a NO response. You are
On Wed, 17 Dec 2003, Christof Drescher wrote:
Just to make it totally clear to me: A message can be removed from the
session-state list of \Recent messages ONLY by expunge?
Correct.
Or the other way round: A server MUST NOT change the \Recent flag for a
single message at any time until a
On Wed, 17 Dec 2003, Christof Drescher wrote:
I'd be interested to see your argument for MESSAGES, because I assumed
some coherence between MESSAGES and EXISTS, which is used to announce
new mail in selected mailboxes. Or am I off the track again?
The problem is that prior state is implied.
On Tue, 16 Dec 2003, Christof Drescher wrote:
If this is the case, then what is the purpose of RECENT anyway?!
I find recent to be very useful for virus/spam checking. If a session
sees that a message is recent, then it is responsible for doing virus/spam
checking on that message. If the
On Mon, 15 Dec 2003, Pawel Salek wrote:
Is the example in section 6.4.4. of rfc3501 correct?
See ftp://ftp.cac.washington.edu/mail/rfc3501-errata or the rfc-editor.org
errata web page.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public
Here is one way to implement \Recent:
Think of mail that has been newly delivered, but not yet processed by an
IMAP server, as in recent state. Perhaps it has not yet been assigned a
UID, perhaps it's in a spool area waiting to be moved to the mailbox.
Another example is a traditional UNIX
On Sun, 14 Dec 2003, DINH Viet Hoa wrote:
But don't you think there is some waste of bandwidth using SEARCH
instead of STATUS to get the number of UNSEEN messages ?
If that is be anything other than a trivial consideration, there are other
conditions in the selected mailbox which are simple to
On Sun, 14 Dec 2003, DINH Viet Hoa wrote:
The definition of RECENT messages after a NOOP could be used.
I mean since the last time we got a RECENT unsollicited response (or
sollicited).
What is recent in the selected mailbox has no relationship to what is
recent in a STATUS done by any other
On Sun, 14 Dec 2003, DINH Viet Hoa wrote:
The fact is that I do not need to fetch the message list but only the
count of messages. But I still want the count of messages because the
user wants to know if there are new or unread messages before he knows
if it is worth fetching the list of
On Thu, 11 Dec 2003, Arnt Gulbrandsen wrote:
The protocol doesn't forbid
poor-quality implementations.
You hit the nail on the head right there.
That is absolutely correct; the protocol doesn't forbid poor-quality
implementations.
Poor-quality implementations are just as harmful as
On Fri, 12 Dec 2003, DINH Viet Hoa wrote:
On Thu, 11 Dec 2003, Marcel Crasmaru wrote:
Suppose that message of sequence number 1 is unseen.
The client issue the command:
C: tag fetch 1 body[]
and the server fetches the message but for some reasons
it can not flag the message as
On Wed, 10 Dec 2003, Richard Bang wrote:
004 STORE 1 FLAGS (\Seen)
* 1 FETCH (FLAGS (\seen) UID 12)
004 OK STORE Completed but only for this session
You shouldn't return UID for a non-UID FETCH that does not mention UID.
Otherwise, it will break RFC 1176 clients. Better:
004 STORE 1 FLAGS
On Wed, 10 Dec 2003, Patrick Bennett wrote:
Well, in that case one would think that if you support IMAP4rev1
according to RFC2060, then by definition you support IMAP4rev1 (rfc3501).
That is certainly correct for a client.
Unfortunately, I don't believe that is the case. RFC3501 has
On Tue, 9 Dec 2003, Antonio Cambule wrote:
That is why I said there should be no problem for me writing an IMAP
Server. I think the most difficult work is done. It's only
understanding the RFCs and examples in there and the methods IMAP works
with.
Your problems were in syntax errors.
This
On Tue, 9 Dec 2003, Richard Bang wrote:
* FLAGS ()
Not compliant. System flags are mandatory-to-implement.
The PERMANENTFLAGS list can be empty though.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
On Fri, 5 Dec 2003, Chun-Ping Man wrote:
user A with account A sends a select-command and
user B with account B sends a select-command too
how does imap know which select command relate to which account ?
IMAP is based upon TCP, which helpfully takes care of identifying separate
sessions.
On Fri, 5 Dec 2003, DINH Viet Hoa wrote:
If this is required, maybe the following statement should be modified :
OK [PERMANENTFLAGS (list of flags)]
A list of message flags that the client can change
permanently. If this is missing, the
On Thu, 4 Dec 2003, Alexey Melnikov wrote:
My question is whether one can just return \* and don't list
previously created keyword?
One can in the same sense that one can implement an IMAP server that
always deletes and expunges all messages (whether or not you had set the
\Deleted flag) when
On Thu, 4 Dec 2003, Richard Bang wrote:
A) any way to declare that all flags will be permanent, i.e. the server
will set any flag on any message
That is what PERMANENTFLAGS does, by listing all the flags that were in
FLAGS, and by including \*.
When you create a new keyword flag, you would
On Thu, 4 Dec 2003, Arnt Gulbrandsen wrote:
I believe the issue is: Does the server need to include all flags that
have ever existed in the mailbox, or merely all flags that currently
exist?
Reading RFC 3501 page 64, either way seems legal. The meaning hinges on
which flags the server is
The closest analog to what SUBSCRIBE/UNSUBSCRIBE manages are the
subscribed newsgroups in a UNIX .newsrc file, or the bookmarks in your
favorite browser. LSUB lists the current contents of such a list.
Note that LSUB may include names that do not currently exist; the idea
being that you could
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
MIME part and each part having their parent's ID so
On Mon, 24 Nov 2003, Timo Sirainen wrote:
Body location was added to BODYSTRUCTURE in RFC3501. Are you going to
keep adding new fields to it whenever new useful fields are invented?
By design, MIME encourages the use of existing fields rather than a
boundless addition of new fields. Most new
I suggest that you buy a copy of the following two books:
1) Internet Email Protocols: A Developer's Guide, by Kevin Johnson,
published by Addison Wesley, ISBN 0-201-43288-9.
2) Managing IMAP, by Dianna Mullet Kevin Mullet, published by
O'Reilly, ISBN 0-596-00012-X.
The first book describes
On Thu, 20 Nov 2003, DINH Viet Hoa wrote:
As I could understand, in IMAP, we can keep a track of number of
messages. But what about recent or unseen messages ? should we always use
SEARCH to get the exact count ?
Any change to the RECENT count is noted with a new untagged RECENT count.
This is
On Sat, 8 Nov 2003, Nathan Brown wrote:
When I added an IMAP account and pressed check mail, it retrieved the
new messages as well as adding everything in my home directory on the
mail server to my folders list on my email client! What should I do?
This is a bug/misfeature of your IMAP client;
Does anybody know what IMAP server implementation issues that error
message? Or does anybody recognize this as being an error message from
their IMAP server?
We have a user who is encountering problems because the IMAP server is
giving that error in response to a SEARCH command.
-- Mark --
On Fri, 7 Nov 2003, Ken Murchison wrote:
We have a user who is encountering problems because the IMAP server is
giving that error in response to a SEARCH command.
The user can't give you anything other than the error message? They
can't glean anything from the banner or find any
On Tue, 4 Nov 2003, Timo Sirainen wrote:
On Tue, Nov 04, 2003 at 12:46:47PM -0500, Paul Jarc wrote:
I'm writing an entirely read-only IMAP server; it's mainly intended
for serving mailing list archives. Just like a web archive, it lets
anyone in (PREAUTH greeting),
Many clients don't
On Tue, 4 Nov 2003, Arnt Gulbrandsen wrote:
It make sense. Imagine a server processing a search:
for each message in the mailbox:
think about whether this message matches the search
if there are any matches that have been known for two seconds:
send all matches so far in a
On Thu, 30 Oct 2003, Richard Bang wrote:
I will exclude Pine from my discussion because, while it is much liked
by Marc, I have never heard of a single commercial user using it and
Mark
none of the customers I have ever asked have heard of it. Given that
many of us work in the
On Thu, 30 Oct 2003, DINH [iso-8859-15] Vi$Bj(Bt Ho$B`(B wrote:
could you be more explicit about the problem with delete-expunge model and
unsolicited data model ?
Many clients wish to present a trashcan type graphical model, and expect
the server to implement that model by means of a Trash
On Thu, 30 Oct 2003, Yanik Charbonneau wrote:
3 Linux servers serving imap/pop for 5 (1000 active) users from nfs
mounted homes. Using mbox format. Is this possible? Apperently not!
It's supposed to be possible; however, some NFS implementations allow the
buffer cache to get out of sync
On Mon, 27 Oct 2003, Arnt Gulbrandsen wrote:
Do not attribute to malice that which can be adequately explained by
ignorance/release pressure/lack of time/blah/blah. So far, every
Microsoft programmer I've spoken to seemed to try hard. (I'm not saying
they succeed, but I _am_ saying they don't
On Mon, 27 Oct 2003, Alexey Melnikov wrote:
We have seen this happen over and over again. The documents are broken.
Mark, this is not constructive. Please, suggest concrete changes.
The I-Ds that Rob has released are those changes. We need to push to get
those I-Ds reviewed and approved.
On Mon, 27 Oct 2003, Ken Murchison wrote:
But given the number of protocol bugs that we have seen
(and remain unfixed), I would question whether the specs are consulted
regularly or interop testing is done with non-Microsoft products. There
are plenty of ways that the SMTP GSSPI bug could
On Fri, 24 Oct 2003, Slavo Uhrin wrote:
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
Hi Bob -
Please review the following rewritten RFC 3501 errata and see if it
matches with your criteria for inclusion on the RFC Editor errata.
Thanks,
-- Mark --
Section 2.3.1.1, page 8:
old:
A 32-bit value assigned to each message, which when used with the
unique identifier
Philip Guenther is right on both counts. Below is the amended errata.
Thanks all for the help!
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
Section 2.3.1.1, page 8:
old:
A 32-bit value
On Fri, 17 Oct 2003, Bob Braden wrote:
Unfortunately that seems to fall outside what we would consider to be
an erratum. It is a substantive change to the document. If it's
important, you could publish 1-page containing it. There is no
rule that RFCs have to be longer than 100 pages ;-)
Hi
On Fri, 10 Oct 2003, Slavo Uhrin wrote:
What exactly should server do when fetching a message with invalid
MIME header or body?
If you are talking about a message with RFC 2822 or MIME syntax errors,
the answer is:
Garbage In, Garbage Out
The server may do whatever it wants. If it
On Fri, 10 Oct 2003, Chris Wilson wrote:
squirrelmail says it'll improve my performance, kinda makes sense.
http://www.squirrelmail.org/wiki/en_US/SquirrelMailPerformance
That document is wrong. This is a case where a little knowledge is a
dangerous thing, since it transforms into myth.
--
On Fri, 10 Oct 2003, Marc Groot Koerkamp wrote:
Talking about imap proxies, are there imap proxies around that do more
then handle the login stage only. I.e. buffering all the unsollicited
responses between 2 pageloads (in case of webmail). And if they do, are
there limitations to the amount
On Fri, 10 Oct 2003, Simon Josefsson wrote:
Are there inetd implementation that doesn't result in a fork() +
exec()? A standalone implementation might remove the need for a
fork() + exec(), which would improve performance.
Each UW imapd must run in its own process. Your question is therefore
On Thu, 9 Oct 2003, Marc Groot Koerkamp wrote:
According me the courier response is wrong, uw and cyrus responses are
right.
Courier is quite broken, and has always been broken. Courier is not an
IMAP server; and sites which run Courier do not offer IMAP.
I gave up on its author some time
On Wed, 8 Oct 2003, Mark Champion wrote:
It is IMAP. I use IMAP for pine and squirrelmail.
You mentioned POP. So, are you using both IMAP and POP?
If so, what POP server implementation?
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public
On Tue, 7 Oct 2003, Arnt Gulbrandsen wrote:
How? Is there an IMAP extension? Can you point me to a document defining
how other clients should use the same address book and interoperate
with Pine?
Address books are just ordinary mailboxes, but in a form that Pine can
use. Presumably, any
Pine supports remote address books via IMAP. It works quite well,
although I don't know if any non-Pine IMAP clients support it.
We do not support ACAP at UW. I do not know if Outlook or Mozilla support
ACAP.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting,
On Mon, 6 Oct 2003, Mark Champion wrote:
I understand that message UID order is somehow mixed up, but I don't
know how to fix it.
You can't fix it. All you can do is prevent it from happening again.
You are almost certainly using traditional UNIX mailbox format.
Something other than [imapd
On Sun, 5 Oct 2003, Nathan Brown wrote:
I have recently compiled uw-imap (make bsf SSLTYPE=none) and whenever I
try to login with any system user (excluding root) it rejects my login.
* OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS LOGINDISABLED] sentinelc0de.net
IMAP4rev1 2003.339 at
does this mean that if we get the list of all messages of a mailbox
and whether we sort them using UID or sequence number, we will get the
same sequence ?
Yes.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para
On Thu, 2 Oct 2003, David Harris wrote:
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
Yes.
IMAP's unsolicited data
Your easiest approach would be to start with one of the existing
one-message/one-file drivers in UW imapd; that is, the mh or mx drivers.
mx is preferable, since it fully support IMAP; mh is a compatibility mode
driver which has only limited IMAP support. mx uses a separate file,
.mxindex, in
On Tue, 23 Sep 2003, Rob Siemborski wrote:
If Craig is going to be hacking a new mailbox format backend onto whatever
server, I'm almost certain he'll be happier with UW, since UW abstracts
the format of the mailboxes away from the protocol layer significantly
better than Cyrus does (since
On Fri, 19 Sep 2003, Arnt Gulbrandsen wrote:
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
On Fri, 19 Sep 2003, Andreas Aardal Hanssen wrote:
IMAP provides a transparent interface against any mail store, and IMAP
client should not have to deal with different mail stores as long as
both they and the server both speak perfect IMAP.
Correct.
If my client needs to know how \Noselect
On Thu, 18 Sep 2003, Larry Osterman wrote:
One really simple example of a store that has \NoSelect name with
children is the NNTP store. An IMAP server that exposes an NNTP
hierarchy exposes comp.mail.imap even though there is no comp newsgroup
- such a store has to expose comp as a \NoSelect
I agree. I've updated ftp://ftp.cac.washington.edu/mail/rfc3501-errata
to note this.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
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.
Then that the concensus
On Tue, 16 Sep 2003, Rob Siemborski wrote:
I suppose this depends on your definition of harmless. I wouldn't want a
server that doesn't do this declared at all noncompliant.
Agreed; there is no harm in not doing this if the server does not have
have such a thing as a \NoSelect name without
On Tue, 16 Sep 2003, Ken Murchison wrote:
For those of us still trying to understand the downsides of this, can
you provide an example of how such ambiguity would case incorrect
client behavior?
If LIST does not inform the client that the name exists, then the client
may attempt a CREATE
On Tue, 16 Sep 2003, Arnt Gulbrandsen wrote:
If a store can contain entities that are both \noselect and \noinferior,
then IMHO it follows that said store is not (exclusively) a mail store.
Correct.
So, why should the IMAP server be telling the IMAP client about entities
that have nothing to
On Tue, 16 Sep 2003, Ken Murchison wrote:
I consider this to be a bug in RFC 3516. If it intended to make BINARY[]
valid, it should have used the RFC 3501 section rule.
Fetching BINARY[..] for message/rfc822 body part has the same problem.
As does MULTIPART/...anything...
Do you have any
On Tue, 16 Sep 2003, Pete Maclean wrote:
Consider a store that can contain email messages, appointments, addresses,
notes, etcetera, with items of each class restricted to separate containers
but with all such containers in a common hierarchy. Am I correct in
thinking that this would be an
On Tue, 16 Sep 2003, Rob Siemborski wrote:
I don't think IMAP has anything to say on the matter, really, since the
specification has remained silent on the issue.
There is quite a bit of IMAP which is unsaid but (for better or worse)
thought to be obvious because it was the useful behavior.
In
On Tue, 16 Sep 2003, Ken Murchison wrote:
what you are driving at. Maybe I'm just being thick, but why should a
client have to worry about the difference between foo and foo/?
It doesn't; foo does not match foo/% but foo/ does, so foo/ has to be
used.
Do
mainstream clients (other than Pine)
On Tue, 16 Sep 2003, Timo Sirainen wrote:
Unless you mean that in some cases client would want to ask just
foo/% without knowing if foo exists or not? Why would it do that?
Yes, I mean that. It does that because that's a view configured in the
client.
-- Mark --
On Tue, 16 Sep 2003, Ken Murchison wrote:
Why should a client have to create foo/ as a placeholder before creating
foo/bar? Why not just create foo/bar in the first place?
You're asking the wrong question. What if foo/bar is created, and then
deleted. The Cyrus attitude is that there is
On Mon, 15 Sep 2003, Arnt Gulbrandsen wrote:
That client is asking information about mailboxes whose names start with
foo/ and contain exactly one /, right?
foo does not match that, so why should the server mention foo at all?
foo/ is just one of the umpteen million possible names that don't
On Mon, 15 Sep 2003, Timo Sirainen wrote:
Hmm. So is it necessary to send foo/ at all if at least one of it's
children is listed?
IMHO, yes. Otherwise the behavior is inconsistent
1 create dir/
2 list dir/%
Is it required to show the dir/ entry?
Yes, it is. The only difference between
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:
section-binary = [ section-part ]
I consider this to be a bug
On Tue, 16 Sep 2003, Timo Sirainen wrote:
Maildir itself doesn't have any standard where other than INBOX should
be placed. Courier's Maildir++ places everything into ~/Maildir/
directory with '.' separating hierarchies. So it's possible to create
.1.2 directory without having .1.
OK, I
On Mon, 15 Sep 2003, Timo Sirainen 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:
section-binary = [ section-part ]
I consider this
On Mon, 15 Sep 2003, Ken Murchison wrote:
I guess we didn't do a very good job during last call of this doc ;)
I've only stumbled into these issues while implementing it. Maybe (as
Rob suggested offline) that independent interoperable implementations
should be a prereq (or at least strongly
On Mon, 15 Sep 2003, Lawrence Greenfield wrote:
Cyrus has
never had this behavior.
Cyrus does not have such a thing as a \NoSelect mailbox with no children.
On a server which has such a thing as a \NoSelect mailbox with no
children, it becomes very important to respond to foo/% with foo/ since
On Mon, 15 Sep 2003, Ken Murchison wrote:
However, INBOX/ does; and if INBOX is not \NoInferiors then that name
should be shown.
Are you saying that a client depends on this in order to determine that
the mailbox can contain submailboxes?
Yes.
If a server returns INBOX and not
On Mon, 15 Sep 2003, Rob Siemborski wrote:
While I think its somewhat bizarre to report a leaf mailbox that is
\NoSelect and doesn't have any children, I can atleast appreciate why this
is necessary in some environments. However, as you say, such a case does
not apply to all servers (and
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. The change was to
On Thu, 11 Sep 2003, warren l brown wrote:
s : * 2 EXPUNGE
s : * 1 EXPUNGE
For starters, I think that the responses need to be reordered:
s : * 1 EXPUNGE
s : * 2 EXPUNGE
No. The original example expunges original messages 1 and 2. Your
example expunges original messages 1 and 3. If the
On Thu, 11 Sep 2003, Abhijit Menon-Sen wrote:
No. Note that C2 STOREs +FLAGS.SILENT, and is thus not sent an update of
message #2's flags. The FETCH response is telling it about the change to
message #1 by C1.
You're correct.
As the Japanese say, even monkey falls from the tree. ;-)
-- Mark
On Wed, 10 Sep 2003, Andreas Aardal Hanssen wrote:
Mozilla's
IMAP client interprets the \NoSelect as an implicit \NoInferiors, that is
- it assumes that Dev has no submailboxes.
If true, that is certainly a bug in Mozilla's IMAP client. \NoSelect
certainly does not imply \NoInferiors; in
On Wed, 10 Sep 2003, Larry Osterman wrote:
My take is that this is a bug of Mozilla - \NoSelect means exactly what
it says - the mailbox has no inferiors.
can not be selected
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from
On Mon, 8 Sep 2003, David Harris wrote:
I'm looking for guidance on the best practice when handling syntactically
invalid message id's in FETCH ENVELOPE responses.
It was my intent when defining IMAP that an IMAP server not do any special
syntax handling of the Message-ID; that is, it would
UW imapd implements RFC 2193 if the underlying mail store does. None of
the supplied mail store drivers do, but the means to add it is
straightforward.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
On Fri, 29 Aug 2003, Rick Updegrove wrote:
Does wu-imap support ACL (Access Contol Lists)?
Presumably you mean UW imapd. UW is the University of Washington in
Seattle; WU is Washington University in St. Louis.
UW imapd does not support RFC 2086 ACL. It is not technically possible to
support
July 2003 02:37 am, Mark Crispin wrote:
Have you read the FAQs in imap-200?/docs/FAQ.txt or
http://www.washington.edu/imap?
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
On Wed, 27 Aug 2003, William O'Shea wrote:
You only have to get the config file right once and
it would stay that way through any upgrade.
Actually, that isn't true; or rather, that has historically not been the
case with imapd.
There is an unsupported config file capability. There is a way
On Tue, 20 Aug 2003, Timo Sirainen wrote:
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 matching at least..
There is a
On Mon, 11 Aug 2003, Pete Maclean wrote:
A related issue is that I feel the need for some clarification on the whole
business of commands completely succeeding or completely failing. I have
come to regard this as an important dictum for IMAP implementation as it
has been mentioned a few times
On Wed, 16 Jul 2003, Timo Sirainen wrote:
Shared mailboxes are exactly where I was thinking this read-lockless
store would work very well. You never have to wait for locks when
you're reading the store, and more importantly you never have to wait
for readers to finish before you get a write
On Wed, 16 Jul 2003, Timo Sirainen wrote:
What if the mailbox is all the time opened by other clients, are the
messages ever really expunged?
Then the space never gets recovered, at least not until there is some sort
of system maintenance garbage-collection.
That's why I'd rather not have any
On Wed, 16 Jul 2003, Timo Sirainen wrote:
rename(). You rewrite the file and rename it over the old one. Next
synchronization check notices this and reopens the file.
This would require exclusive locking for all modifications though.
Yes; otherwise you have to synchronize changes in the old
701 - 800 of 1002 matches
Mail list logo
