Ken Murchison wrote:
. LIST "" INBOX.cyrus.%
* LIST (\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 ha
Ken Murchison wrote:
Alexey Melnikov wrote:
Mark Crispin wrote:
On Thu, 30 Sep 2004, Alexey Melnikov wrote:
The mailbox "/m/aaa" doesn't match mailbox pattern "/m/aaa/%", so
it shouldn't be returned.
However, hierarchial name /m/aaa/ would match and could be returned
Mark Crispin wrote:
On Thu, 30 Sep 2004, Alexey Melnikov wrote:
The mailbox "/m/aaa" doesn't match mailbox pattern "/m/aaa/%", so it
shouldn't be returned.
However, hierarchial name /m/aaa/ would match and could be returned as
a \NoSelect name.
If this is a MUST
Andreas Aardal Hanssen wrote:
On Wed, 29 Sep 2004, David Truckenmiller wrote:
R2: * LIST () "/" "/m/aaa"
R2: * LIST () "/" "/m/aaa/one"
This. It has been discussed before; see the archives for details.
The mailbox "/m/aaa" doesn't match mailbox pattern "/m/aaa/%", so it
shouldn't be return
Richard Bang wrote:
Hi,
I have a query regarding the ACL extension.
Could some kind person point me to the right place to ask about it?
IMAPEXT WG <[EMAIL PROTECTED]> is the best, but [EMAIL PROTECTED]
is fine too.
I am the editor of the ACL draft, so feel free to email me directly.
Alexey
Mark Crispin wrote:
It looks to me that you can not use CRAM-MD5 authentication if you
allow user names with a space.
This is addressed in draft-ietf-sasl-crammd5: when extracting digest the
server should look for the rightmost space. Everything to the left is a
username.
So, spaces are allowed
I've just submitted a new revision of the "Synchronization operations
for disconnected IMAP4 clients" document. I intend to publish the
document soon, so I would like to solicit review of the document.
Original Message
Subject:I-D ACTION:draft-melnikov-imap-disc-04.txt
Antonio Cambule (STÜBER SOFTWARE) wrote:
Hi,
I'm doing the implementation for UIDs and thought that the UID will be
stored within the Mail itself.
Taking a look at RFC 2822 I couldn't find anything about UID, the
Identification Number is called Message ID.
Is UID = Message ID?
No. UID is 32 bit
Simon Josefsson wrote:
Cyrus Daboo <[EMAIL PROTECTED]> writes:
The draft suggests a new convention for transient IMAP capabilities,
which should be used until the document describing an IMAP extension
becomes RFC. For example, the transient capability for SASL-IR extension
as defined in draft-si
Rob Siemborski wrote:
In released versions or just internally?
If in released versions, I suggest a Last Call for the SASL-IR draft
right now.
Released versions in both cases. I was hoping to wait until the new
SASL draft was last called, in order to deal with any last minute
modifications that
[Sorry for cross-post, please limit your replies to IMAPEXT]
Rob Siemborski wrote:
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.)
(oh -- Squirrelmail [and I presume
[EMAIL PROTECTED] wrote:
Agreed. However, is it possible to encase all attributes to the
authenticate/login commands as per XML?
Ex:
b authenticate plain (SASLIR AGFybnQAdG5yYQ==) (SID 1234432143)
This way it is permanently extensible?
This would be possible, however as Rob pointed out there is al
Rob Siemborski wrote:
On Fri, 16 Jul 2004, Alexey Melnikov wrote:
The alternative proposal is to use () only to pass additional
parameters:
b authenticate (SID 1234432143) plain AGFybnQAdG5yYQ==
Atleast Arnt proposed this syntax:
That was Corby, I think.
b authenticate login (SASLIR dGVzdDg
Rob Siemborski wrote:
On Thu, 15 Jul 2004, Alexey Melnikov wrote:
An alternative would be to put AUTHENTICATE options in () before the
SASL mechanism name.
While it might be slightly cleaner, both UW and Cyrus both already
implement the original AUTHENTICATE syntax.
The alternative proposal is
Ken Murchison wrote:
Alexey Melnikov wrote:
For the latter case the current syntax is
b login arnt tnra (SID 1234432143)
which will do exactly what you are asking for. Extending LOGIN also
saves a round trip.
This *could* still work with SASL-IR because AFAIR '(' isn't a valid
b
Alexey Melnikov wrote:
Arnt Gulbrandsen wrote:
Hi,
draft-ietf-lemonade-reconnect and
draft-siemborski-imap-sasl-initial-response conflict, because they
extend AUTHENTICATE in the same way.
We've already marked this as an open issue in the reconnect draft.
I've suspected, but I didn&#
Arnt Gulbrandsen wrote:
Hi,
draft-ietf-lemonade-reconnect and
draft-siemborski-imap-sasl-initial-response conflict, because they
extend AUTHENTICATE in the same way.
We've already marked this as an open issue in the reconnect draft.
I've suspected, but I didn't have time to check. This will be f
[At first I thought that you are trying to subscribe to the mailing list
:-)]
Timo Sirainen wrote:
Is it correct for client to send "SUBSCRIBE mailbox/" command? If yes,
should server treat it the same as "SUBSCRIBE mailbox"? mailbox being
either a directory, or a dual-user mailbox.
I'm wondering
Lyndon Nerenberg wrote:
Have any of you looked at the draft-cadar-dhc-opt-imap-00 draft?
Yes, and I pretty much wrote to the author the same thing that you did.
From the abstract:
This document describes a new option for Email related configuration
information in Dynamic Host Configuration Prot
Antonio Cambule (STÜBER SOFTWARE) wrote:
Hi,
it's me again :-\ . This time: Mailbox Attributes.
Can one mailbox have more than one mailbox attribute at the same time
Yes.
and if so, can they be combined, like:
...\Noinferior \Noselect... or ...\Noinferior \Marked. ?
Yes.
how will an LSUB or L
Michael Wener wrote:
Sorry for the blank message.
What I meant to say was ...
Do you mean a response that would involuntarily transition the client to
the Authenticated state?
Yes.
Alexey
Arnt Gulbrandsen wrote:
[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 co
Andreas Aardal Hanssen wrote:
2) I use imp to access my mail from the internet, but I was thinking why
have a middle man. How about opening up my imap server & just configure my
home outlook to get my mail. What are the pro's or con's? Can I config
IMAP to use SPA or is just SSL good enough?
Mark Crispin wrote:
On Fri, 9 Jan 2004, Tim Showalter wrote:
I tried to spend a few minutes thinking about this over the past couple days.
Mark's implementation is certainly more powerful, although I still find it
really odd. I can't get a good counter argument going.
Yes, it is odd, but
Richard Bang wrote:
Hi,
When doing a SELECT and returning the UNSEEN item the RFC says:
"The message sequence number of the first unseen message in the
mailbox."
What if there are NO unseen messages ? Is zero the valid response
* OK [UNSEEN 0] .
No, unfortunately 0 is not allowed. If there ar
Mark Crispin wrote:
On Thu, 4 Dec 2003, Richard Bang wrote:
I have a question regarding PERMANTFLAGS that I cant resolve from the
RFC (or I just couldn't find it).
Should the PF response include any flags that have been defined by the
client.
Yes. If you offer \* as one of the PERMANENTFL
Mark Crispin wrote:
On Sun, 9 Nov 2003, DINH Viet Hoa wrote:
When we want to define new flags in a client, should we use keywords or
flag extension for that ?
You should use keywords. System flags (flags starting with "\") are
defined in the base specification and are mandatory to impleme
Richard Bang wrote:
Hi,
My company has regression testing on software before release to make
sure that changes we make don't effect performance. Where ever possible
we use external tools to verify operations this then shows that we are
not operating under any false assumptions.
Can anyone suggest
Timo Sirainen wrote:
On Fri, Oct 31, 2003 at 03:12:54PM +0100, Arnt Gulbrandsen wrote:
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. (Se
Richard Bang wrote:
Alexey Melnikov
I don't see the connection between an address book entry and an ACAP
entry!
Addressbook is a piece of an application configuration, so an
addressbook is one of the objects that can be stored in ACAP.
Shared documents?
ICal?
Sure.
You
Richard Bang wrote:
On Behalf Of Arnt Gulbrandsen
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 a
Mark Crispin wrote:
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_
Holger Mauermann wrote:
Scott Otterson wrote:
Can address books be stored and shared in IMAP space in the same way
as messages? I'm on a different OS or client at every location where
I check mail so IMAP email is very handy.
Some time ago I wrote a small program to store address books on
warren l brown wrote:
Assuming a mailbox having at least 2 messages,
and two IMAP clients selecting it, is the following
client(s)/server interaction correct or not? Can
someone point the errors?
c1: a store 1 +flags (\Deleted)
s : * 1 FETCH (FLAGS (\Deleted) UID 3)
s : a OK store
c2: aa store 2 +
Sumeet Agarwal wrote:
Hi ALL,
I'd like to seek some clarification about "shared" vs. "private"
metadata (specifically system flags) as defined by CONDSTORE and
ANNOTATE .
* How can a server let clients know which flags he is treating as
shared and which ones as private?
CONDSTORE exte
Lyndon Nerenberg wrote:
> > On Friday, July 11, 2003, at 03:14 PM, Alexey Melnikov wrote:
> >
> > Lyndon Nerenberg wrote:
> >
> >> $Work, $Personal:
> >>
> >> Is there a need to standardize these? It seems to me that the
>
Lyndon Nerenberg wrote:
> $Work, $Personal:
>
> Is there a need to standardize these? It seems to me that the
> reason for $* flags is to ensure functional compatibility
> between clients. I cannot think of any functionality that would
> be triggered by these flags.
Mark Crispin wrote:
> 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
Edward Hibbert wrote:
> I have a query on how untagged responses should work. I can't see
> discussion of this in 2180 or 2060; apologies if I've missed it.
>
> Suppose:
> - You have a mailbox selected on one session containing 2 messages.
> - 3 messages are APPENDed, and 1 of them expunged by an
Lyndon Nerenberg wrote:
> >> Apple Mail's junk filter uses the Junk, JunkRecorded, and NotJunk
> >> flags.
> >
> > New Mozilla (and Netscape 7.1) use Junk and NotJunk as well. I am
> > wondering
> > if we should just standardize those (and $AutoJunk/... as suggested by
> > Chris) in order not to b
Cyrus Daboo wrote:
> Hi Alexey,
>
> --On Thursday, July 10, 2003 03:18:43 PM -0600 Alexey Melnikov
> <[EMAIL PROTECTED]> wrote:
>
> |> On Thursday, July 3, 2003, at 11:42 AM, Alexey Melnikov wrote:
> |>
> |> > I believe Junk and NoJunk are in use (n
Lyndon Nerenberg wrote:
> On Thursday, July 3, 2003, at 11:42 AM, Alexey Melnikov wrote:
>
> > I believe Junk and NoJunk are in use (no leading $).
> > Does anybody have any information on how there are used?
>
> Apple Mail's junk filter uses the Junk, JunkReco
Mark Crispin wrote:
> 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
Chris Newman wrote:
> The $adult keyword should be removed from this draft on the grounds that the
> definition is too vague to provide any value for interoperability. The
> mechanism is inappropriate as the rules for what constitutes adult content
> varies significantly by country, state, city,
Rob Siemborski wrote:
> On Tue, 1 Jul 2003 [EMAIL PROTECTED] wrote:
>
> > The aim of this document is to document some common [IMAP4] keywords
> > for the purpose of improving interoperability between different IMAP
> > mail clients. The document both documents some keywords already in
> > use, as
David Woodhouse wrote:
> On Thu, 2003-03-13 at 00:34, Alexey Melnikov wrote:
> > Please, have a look at draft-melnikov-imap-condstore-10.txt. Your timestamp is
> > called modseq (modification sequence) in the draft. FLAGS-VALIDITY is called
> > HIGHESTMODSEQ in the documen
Timo Sirainen wrote:
> Also do you really have to return MODSEQ messageset for each SEARCH and
> SORT? You're just returning the search results twice. Why not add the MODSEQ
> into the untagged reply itself? ie. "* SEARCH 1 2 4 10 (MODSEQ 123)". Since
> client specifically asked for the MODSEQ, th
Please, have a look at draft-melnikov-imap-condstore-10.txt. Your timestamp is
called modseq (modification sequence) in the draft. FLAGS-VALIDITY is called
HIGHESTMODSEQ in the document.
The functionality you propose can be build as a small extension to CONDSTORE
(and yes, other people already prop
Please, have a look at draft-melnikov-imap-condstore-10.txt. Your timestamp is
called modseq (modification sequence) in the draft. FLAGS-VALIDITY is called
HIGHESTMODSEQ in the document.
The functionality you propose can be build as a small extension to CONDSTORE
(and yes, other people already prop
Timo Sirainen wrote:
> On Tue, 2003-03-04 at 18:21, Steve Hole wrote:
> > > That's what I meant with "fetching BODY", except I remembered BODY was
> > > enough. But still, fetching BODYSTRUCTURE is pretty much useless
> > > cpu/bandwidth usage just for one paperclip icon.
> >
> > No, it's not.
> >
Timo Sirainen wrote:
> Just a thought - anyone else interested about this?
>
> Paperclip icon indicating attachment can be pretty useful and many
> clients want it, but figuring out if it should be put there requires
> fetching BODY or the whole message.
Actually, it should be sufficient to fetch
Rick Block wrote:
> Does anyone know of a cross listing of imap4 extensions
> and the clients that implement them? I'm aware of Alexey
> Melnikov's extremely useful pages at
>
> http://www.sendmail.org/~ca/email/mel/Links.html
>
> which includes a page listing extensions supported by a few
> serv
ED in initial response suggest that cleartext authentication
with LOGIN is disabled/not supported on the server.
Cheers,
Alexey Melnikov
__
R & D, ACI Worldwide/MessagingDirect
Watford, UK
Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel
I speak for myself only, not for my employer.
__
Andreas Aardal Hanssen wrote:
> >If they do need to grow, server would have to remember the last
> >UIDVALIDITY for deleted mailboxes, so RENAME could check if the
> >UIDVALIDITY must be changed. I don't like that behaviour. It's very
> >unnecessary and requires permanent space for deleted mailbox
Simon Josefsson wrote:
> Andreas Aardal Hanssen <[EMAIL PROTECTED]> writes:
>
> > On Wed, 22 Jan 2003, Alexey Melnikov wrote:
> >>> RENAME, on the other hand, is broken on almost all servers.
> >>Maybe. But it is not impossible to fix RENAME in serve
Andreas Aardal Hanssen wrote:
> On Wed, 22 Jan 2003, Alexey Melnikov wrote:
> >> RENAME, on the other hand, is broken on almost all servers.
> >Maybe. But it is not impossible to fix RENAME in servers staying complaint
> >with IMAP4rev1.
>
> Compliant is one thin
> RENAME, on the other hand, is broken on almost all servers.
Maybe. But it is not impossible to fix RENAME in servers staying complaint
with IMAP4rev1.
And I don't buy the argument that a server can't store 4bytes UIDVALIDITY
somewhere when mailbox is deleted/renamed.
> The Cyrus server (includ
Oops, I've hit Send button too soon...
Andreas Aardal Hanssen wrote:
> Can an IMAP server implement RENAME in such a way that it is compliant
> with IMAP4rev1?
>
> I am thinking in particular with what was mentioned earlier about the
> sequence
>
> RENAME a b
> CREATE a
> DELETE a
> RENAME b a
>
Andreas Aardal Hanssen wrote:
> Can an IMAP server implement RENAME in such a way that it is compliant
> with IMAP4rev1?
>
> I am thinking in particular with what was mentioned earlier about the
> sequence
>
> RENAME a b
> CREATE a
> DELETE a
> RENAME b a
>
> ...in which the UIDVALIDITY.UID criter
IMHO, the best place to look is:
http://www.imap.org/products/
Alexey
y handle "", but I don't really believe
that any client is using "".
Regards,
Alexey Melnikov
__
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508
Home Page: http://orthanc.ab.ca/mel
I speak for myself only, not for my employer.
__
y to
delete a mailbox that is currently selected (in the same session).
See also RFC 2180.
Alexey Melnikov
__
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508
Home Page: http://orthanc.ab.ca/mel
I speak for myself only, not for my employer.
__
Alexey Melnikov wrote:
> Abhijit Menon-Sen wrote:
>
> > At 2002-08-19 18:20:27, [EMAIL PROTECTED] wrote:
> > >
> > > "RFC2060 has an error in the definition of data-value. The syntax allows
> > > the value to be empty, since '#flag' includ
raft-crispin-imapv-17.txt) updates the grammar thus:
>
> flag-list = "(" [flag *(SP flag)] ")"
Thus the empty value MUST be supported.
> store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP
>
on mandatory? (I'm sure it is, but
> > I'd like this confirmed by greater minds).
>
> I'm not sure that I understand your question. Either a zero-length
> literal or a zero-length quoted-string will suffice.
If I understood the question correct
Mark Crispin wrote:
> On Wed, 12 Jun 2002 02:51:49 -0600, Alexey Melnikov wrote:
> > I came across similar bug in Netscape 4.79: it can't cope with UIDs bigger
> > than 2**32-1, Netscape just doesn't display them!
>
> Do you mean 2**31-1?
Yes, that is what I'
re in sending this information to the IMAP mailing list.
If I knew an email address of a person at Netscape I can complain to, I would rather do
that. Can a person from Netscape client team contact me directly, as I have more bugs
to report.
Regards,
Alexey Melnikov
__
two evils.
> Fortunately for Windows developers, Microsoft has solved the problem for
> us. Modern versions of Windows have SSL and TLS support in SSPI.
Just to be fair: on Windows 2000 and beyond there is a SSPI provider for
DIGEST-MD5.
Regards,
Alexey Melnikov
___
Mark Crispin wrote:
> On Tue, 4 Jun 2002, Alexey Melnikov wrote:
> > > [IMAP-DISC] Austein, R., "Synchronization Operations for Disconnected
> > > IMAP4 Clients", Work in Progress.
> > I don't recognize this document. It either became an RFC or ex
> [IMAP-DISC] Austein, R., "Synchronization Operations for Disconnected
> IMAP4 Clients", Work in Progress.
I don't recognize this document. It either became an RFC or expired a long time
ago.
Regards,
Alexey Melnikov
__
ble to me. But I would rather not mention KERBEROS_V4, as
GSSAPI made it obsolete. Also my preference in listing mechanisms would be:
DIGEST-MD5, GSSAPI, CRAM-MD5.
(I wish I have some statistics on usage of different mechanisms)
Regards,
Alexey Melnikov
__
R & D, A
> begin quotation by Alexey Melnikov on 2002/5/31 10:15 -0600:
>
> > Having said that I would like to leave at least one non-plaintext SASL
> > mechanism as mandatory to implement. So, what about
> >
> > Clients: MUST TLS+AUTH=PLAIN and DIGEST-MD5
> > Server
andatory to implement. So, what about
Clients: MUST TLS+AUTH=PLAIN and DIGEST-MD5
Servers: MUST TLS+AUTH=PLAIN or DIGEST-MD5
What client implementors think? I don't feel that I have a moral ground to
make a decision for client implementors, as I currently not writing one,
although I used to a l
GaÌl Roualland wrote:
> Alexey Melnikov a écrit :
> >
> > Paul Smith wrote:
> >
> > > At 13:41 31/05/2002 +0200, Andreas Aardal Hanssen wrote:
> > > >Say a mailbox has 1000 messages in it, and the highest UID is 1600. Which
> > > >is the cor
t; >
> >1 UID FETCH 1601:* FLAGS
> >* 1000 FETCH (UID 1600 FLAGS (\Seen))
> >1 OK FETCH completed.
>
> The first one.
No, the second one, because * is translated to 1600 for UIDs.
Regards,
Alexey Melnikov
__
R & D, ACI Worldwi
Mark Crispin wrote:
> On Wed, 29 May 2002, Lawrence Greenfield wrote:
> > Our local site policy doesn't offer DIGEST-MD5---but
> > that isn't what we're talking about.
>
> The point seems to be interoperability between compliant implementations.
> A client which only implements DIGEST-MD5 is not
agree.
> > Both options have open-source code available and many existing IMAP servers
> > already comply.
>
> Perhaps there are IMAP servers which have it, but I haven't seen any; and
> I know of no clients which have it.
Regards,
Alexey Melnikov
___
even less deployed than DIGEST-MD5 and the document is not
stable.
But this is not to discourage you to implement it in your client/server,
if any ;-).
Regards,
Alexey Melnikov
__
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508
Home Page: http://orthanc.ab.ca/mel
I speak for myself only, not for my employer.
__
chanism for IMAP is
probably CRAM-MD5, but LDAP/ACAP/BEEP recommend DIGEST-MD5.
I tend to agree that a separate document should be used, however there is none
at this time. And I don't think that the information about mandatory to
implement belongs to SASL spec for the same reasons it d
f it
> so choses.)
>
> MOVE also causes complexity for ACL: you're requiring both the 'd'
> right on the source folder and the 'i' right on the destination
> folder. Off-hand, I can't think of an IMAP command that requires
> ACLs on two distinct
0) and POP (RFC 1734).
How to implement GSSAPI SPENEGO is documented in
draft-ietf-cat-sasl-gssapi-05.txt.
All interested parties should read this document, as it will be Last Called
soon.
Alexey Melnikov
__
R & D, ACI Worldwide/MessagingDirect
Richmond, Surr
regards,
Alexey Melnikov
__
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508
I speak for myself only, not for my employer.
__
ankly, I'd love to have first four questions answered before we start
> discussion on that one.
Should we move this discussion to SASL mailing list?
Alexey Melnikov
__
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508
I speak for myself only, not for my employer.
__
83 matches
Mail list logo
