(\HasNoChildren) "." "INBOX.cyrus.devel"
>* LIST (\HasNoChildren) "." "INBOX.cyrus.sasl"
>* LIST (\HasNoChildren) "." "INBOX.cyrus.sieve"
>. OK Completed (0.000 secs 4 calls)
>
>This looks correct to me. I haven't browsed CVS to see when this might
>have been fixed.
Mark and Andreas are saying that the second command should have
also returned
* LIST (\Noselect) "." "INBOX.cyrus."
Philip Guenther
response for /m/aaa/ would
be a lie. If nothing else, the client would rightfully expect that if
it then created "/m/aaa/bar" the new folder would inherit its ACL from
"/m/aaa/", which isn't true.
(While I understand the usefulness of \Noselect,
Hmm, the relevant sentence in RFC 3501 is
Philip Guenther
mportant thing when communicating with tech-support
is to describe your goal or intent. Spending hours working out how
to do something that turns out to be a step away from the ultimate
goal is frustrating to all involved. There's a good chance that
the discussion of how to attain the real goal would have answered
the original question or rendered it moot.
Philip Guenther
Mark Crispin <[EMAIL PROTECTED]> writes:
>On Tue, 28 Sep 2004, Philip Guenther wrote:
>> What's interesting about Timo's example is that UW-IMAP didn't answer
>> the question that was asked it. ("from to") != (from to) == ("from" "to&qu
regular fetch, but what does it do when you pass this?
>
>x fetch 1 body.peek[header.fields ("")]
What's interesting about Timo's example is that UW-IMAP didn't answer
the question that was asked it. ("from to") != (from to) == ("from" "to")
Philip Guenther
;] SP header-list /
"TEXT"
header-list = "(" header-fld-name *(SP header-fld-name) ")"
header-fld-name = astring
Philip Guenther
** It'll always provoke a response of either an empty line or nothing
at all, the latter occuring only when th
section 2.3.1.2, and the
implied mapping between them and UIDs are clearly a form of state
created by SELECT (and EXAMINE). The maintence of this state is
described throughout the rfc, particularly in section 5.2 ("Mailbox Size
and Message Status Updates"") and section 7.4.1 ("EXPUNGE Response").
Philip Guenther
[EMAIL PROTECTED]
' mailbox on QUIT. I don't recall much noise then about
how hard it is to do that. Similarly, UNIX vendors have managed to
guarantee that file contents won't vanish underneath an open
filedescriptor just because the last link to the file has been removed.
Why does this generate so much smoke for IMAP?
Philip Guenther
[EMAIL PROTECTED]
to put U+00BD
("vulgar fraction one half") in a mailbox name on a system that
uses '/' as the mailbox delimiter?
Philip Guenther
[EMAIL PROTECTED]
"Christof Drescher" <[EMAIL PROTECTED]> writes:
>Philip Guenther wrote:
>>>Not only that. Two examples: 1) Mails which confidential data should be
>>>erasable as soon as possible; it is not acceptable (especially on heavily
>>>connected mailboxes)
dn't read Richard Gabriel's "Worse is Better" essay
before designing IMAP or he might not have included msgnos in the
protocol at all and we wouldn't be in this situation.
Philip Guenther
[EMAIL PROTECTED]
command provoke an "out of sync" error. Such a protocol would
therefore be unusable over the Internet with 'busy' mailboxes.
Philip Guenther
[EMAIL PROTECTED]
ould just skip messages marked \deleted.
Atomic fetch-and-set of flags is addressed by the CONDSTORE extension,
which I understand to have beeen designed for *exactly* the situation
you describe.
Philip Guenther
[EMAIL PROTECTED]
problem. Note that extending the protocol to, say, add a
"file to trash" command would *not* solve their problem, because the
involved clients wouldn't know to use it. Altering the meaning of
existing commands, on the other hand, breaks *all* clients because no
existing client coul
ne of my sessions
are seeing the \Recent flag, then someone else is obviously watching my
mailboxes.
Philip Guenther
[EMAIL PROTECTED]
ed the TLS cipher
suite TLS_RSA_WITH_NULL_MD5, as that doesn't actually provide
confidentiality.
Philip Guenther
[EMAIL PROTECTED]
age 1, so the second expunge
>is against message 1.
Yes. This *exact* issue (when do expunge response take effect) is
discussed in rfc3501 section 7.4.1, where the EXPUNGE response is
completely described.
Philip Guenther
[EMAIL PROTECTED]
4:
> old:
> C: A284 SEARCH CHARSET UTF-8 TEXT {6}
> S: + Ready for literal text
> C: XX
> S: * SEARCH 43
> S: A284 OK SEARCH completed
The old/existing text does not include the second line (that's the
correction).
Philip Guenther
[EMAIL PROTECTED]
th msgnos in two
different places. The exception proves the rule: section 5.5 makes note
of a limitation on when the client can pipeline UID SEARCH with msgnos,
so such a command can't always be ambiguous.
Philip Guenther
[EMAIL PROTECTED]
19 matches
Mail list logo
