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 as
a \NoSelect name.
If this is a MUST requirement,
Alexey Melnikov wrote:
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
Philip Guenther wrote:
Ken Murchison [EMAIL PROTECTED] writes:
...
2.1.14 is fairly ancient and I don't have a setup that I can test on to
verify. Here is what the current code does:
. LIST INBOX.cyrus*
* LIST (\HasChildren) . INBOX.cyrus
* LIST (\HasNoChildren) . INBOX.cyrus.devel
* LIST
Tim Showalter wrote:
Mark Crispin wrote:
I think that in Cyrus:
LIST foo.bar zap.zowie = foo.zap.zowie
LIST foo.bar. zap.zowie = foo.bar.zap.zowie
LIST foo.bar .zap.zowie = foo.bar.zap.zowie
but I'm not really sure; in practice only the second form is used.
Well, this makes me
Richard Bang wrote:
IMAP as it stands does not seem to cater at all well for shared folders.
The Cyrus server has no problem at all with shared folders. CMU uses
shared folders heavily (hundreds, if not thousands of folders) with
clients ranging from Pine to Mulberry to Outlook to Mozilla.
Larry Osterman wrote:
I'm speaking for Barry, but as I remember, the logic behind allowing
IDLE in the authenticated state is that in the future a server might
have legitimate information to send to the client when in the
authenticated state.
Currently there's no such info that can happen but...
Arnt Gulbrandsen wrote:
Mark Crispin writes:
It calls itself MailSite IMAP4 Server 5.3.6.0 (I think that MailSite
is the name of the ISP; the domain is that user's vanity domain) and
it advertises the IMAP4rev1 ACL NAMESPACE QUOTA AUTH=SCRAM-MD5
AUTH=LOGIN AUTH=CRAM-MD5 capabilities.
Mark Crispin wrote:
It looks like Microsoft finally implemented support for the GSSAPI SASL
mechanism.
Unfortunately, they screwed it up. In their SMTP server, they respond to
the command AUTH GSSAPI with 334 gssapi supported.
Yet more proof that the SASL specifications as currently constituted
Arnt Gulbrandsen wrote:
Ken Murchison writes:
Mark Crispin wrote:
Yet more proof that the SASL specifications as currently constituted
are too complex, and why IMAP should not add initial-response until
the SASL specifications are fixed.
Or its more proof that M$ doesn't care about specs
Larry Osterman wrote:
I certainly take SIGNIFICANT offense at Ken's comment; I'd love for him
to give a real-world example of a WILLFUL misinterpretation of the
specifications from Microsoft, as he implied by his comment. I've seen
lots of instances of stupidity/ignorance, but none of WILLFUL
Mark Crispin wrote:
Hierarchies can be hard (such as UW imapd's export of the UNIX
filesystem) or soft (such as Cyrus).
A hard hierarchy is one in which each level is its own named object. Such
objects may be terminal and/or have other levels of hierachy. Each
non-terminal level contains
Mark Crispin wrote:
On Tue, 16 Sep 2003, Rob Siemborski wrote:
Indeed, I'd argue such a server (which does not have the \NoSelect with no
children case) is equally correct with an implementation that does not
omit foo/ from the list, since none of this special treatment of trailing
hierarchy
Mark Crispin wrote:
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
Mark Crispin wrote:
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
Arnt Gulbrandsen wrote:
Mark Crispin writes:
On Mon, 15 Sep 2003, Rob Siemborski wrote:
If I do a LIST INBOX/%, and I have no sub-mailboxes in my
INBOX, INBOX does not match the pattern -- it is missing the
trailing hierarchy separator.
However, INBOX/ does; and if INBOX is not
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.
--
Kenneth Murchison Oceana Matrix Ltd
Mark Crispin wrote:
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
Lyndon Nerenberg wrote:
I disallow BINARY[] in my server, but I can be convinced that that was a
mistake given that RFC 3516 says that it is OK.
Didn't Ned catch this and ask the RFC editor to make the change before
publication? I have to dig through my email archives and verify what
Lyndon Nerenberg wrote:
--On Monday, August 11, 2003 1:33 PM -0400 Pete Maclean
[EMAIL PROTECTED] wrote:
Suppose that
the server works through the messages, decoding each appropriate MIME
part and sending it. Then suppose it hits one message that has the
part encoded using a method that
What is the meaning of BINARY[]? Is this the same as BODY[] (e.g.,
nothing gets decoded)?
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
--
Mark Crispin wrote:
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
Mark Crispin wrote:
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
Timo Sirainen wrote:
On Tue, 2003-09-16 at 00:21, Mark Crispin wrote:
OK, I understand now. And without some registry of names, there's no good
way to create foo.1. without creating foo.1, and you'd have to have a
placeholder if there is no foo.1.2 (or other child). That may be hard to
do.
Timo Sirainen wrote:
On Tue, 2003-09-16 at 00:59, Ken Murchison wrote:
Looks like Cyrus just creates a normal selectable mailbox with CREATE
mailbox.. I guess there haven't been much complains about that, so I'll
do that as well.
I don't believe that is correct. You can create foo.1.2 without
Mark Crispin wrote:
On Mon, 15 Sep 2003, Rob Siemborski wrote:
If I do a LIST INBOX/%, and I have no sub-mailboxes in my INBOX,
INBOX does not match the pattern -- it is missing the trailing hierarchy
separator.
However, INBOX/ does; and if INBOX is not \NoInferiors then that name
should be
Resurrecting a badly beaten horse...
Is there any interest in having NTLM authentication (as a SASL mech and
possibly as an HTTP mech) documented as an Informational RFC? I believe
I have enough existing documentation (Eric Glass'
http://davenport.sourceforge.net/ntlm.html being the best) and
/etc/syslog.conf
Arvind Kulkarni wrote:
Hi,
I am using Solaris and imap. my requirement is, how do we change the
deamon.notice messages for op3d and imapd from /var/adm/messages to
/var/log/imapoplog?
i would like to separate only imapd and ipop3d notice messages to
/var/log/imapoplog.
Mark Crispin wrote:
You have a point; and this is something that should be addressed in a
document revision.
The IMAP specification (RFC 3501) doesn't allow STARTTLS after
authentication (since STARTTLS is a Not Authenticated state command).
I believe that:
. multiple STARTTLS is absurd
. a
I agree completely. Is anyone aware of client which will break, if it
no longer sees STARTTLS or AUTH= after authentication?
The same questions apply to POP3 also.
Lyndon Nerenberg wrote:
What are you're thoughts on AUTHENTICATE in this regard? Should a
server not advertise the AUTH=
Mark Crispin wrote:
On Fri, 13 Jun 2003, Steve Hanson wrote:
+ go ahead
IMAP protocol error: STORE 1 Command, State, or Parameter
STORE 1 Command, State, or Parameter
() 13-Jun-2003 08:48:41 -0500 {1851}
The first and last line are OK. The numbers in the curly braces are
simply the size
I find it interesting, if not disturbing, that some members of the
usenet community seem to think that mail messages and usenet articles
are not the same thing. AFAICT, from reading the relevant standards,
writing server code for SMTP/LMTP/IMAP/POP3/NNTP, and everyday use, mail
messages and news
Charles Lindsey wrote:
In [EMAIL PROTECTED] Mark Crispin
[EMAIL PROTECTED] writes:
But clients that interoperate with IMAP usually also have the capability
to interoperate with POP3, SMTP, NNTP and maybe even UUCP. I have never
seen any suggestion that those other servers are in any
Mark Crispin wrote:
I recommend instead that USEFOR confine its efforts to NNTP updates and
RFC2822 extensions specific to news, and get a charter going on a WG
dedicated to UTF-8 extension to messaging.
I would be very much interested in participating in such a working group,
and feel
Mark Crispin wrote:
On Tue, 21 Jan 2003, Ken Murchison wrote:
Not only doesn't this do the right thing with
UIDVALIDITY (a flaw that almost every server has), but Cyrus doesn't even
Cyrus maintains UIDVALIDITY.
do the RENAME in an atomic fashion
Does Cyrus change the UIDVALIDITY
Mark Crispin wrote:
The idea behind RENAME was to have a command which would do a rename()
system call at the server end. That has been demonstrated to be an
ill-conceived idea. Not only doesn't this do the right thing with
UIDVALIDITY (a flaw that almost every server has), but Cyrus
Mark Crispin wrote:
On Fri, 10 Jan 2003 13:12:32 -0500, Ken Murchison wrote:
Well, I don't think we can change the current name, because there is
already some deployment.
We can not change the name.
We _could_ add a THREAD=REFERENCES-ONLY or
THREAD=REFERENCES-NOSUBJ
Mark,
91) Change recommendation of optional automatic capabilities in LOGIN
and AUTHENTICATE to use the CAPABILITY response code in the tagged
OK. This is more interoperable than an unsolicited untagged
CAPABILITY response.
Yet, the AUTHENTICATE and LOGIN definitions still list
37 matches
Mail list logo
