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"
* LIS
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 mat
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 requireme
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't have time
David Harris wrote:
I have an IMAP client developer telling me that my server is broken
because I insist on the proper RFC3501 sequencing of steps when the
client submits a literal.
In short, he is saying that he can send the {} followed by the
data in a single packet without waiting for the co
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 w
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...
A
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.
Wha
Arnt Gulbrandsen wrote:
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 doe
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.
Isn
Mark Crispin wrote:
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?
I can tell you its not from Cyrus (not much help, I know).
We have a user who is encountering problems because the I
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
mis
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 spec
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 constitute
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
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
happened.
Mark Crispin wrote:
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/.
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
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
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,
Wo
Mark Crispin wrote:
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 att
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 tha
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 d
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
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
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
Mark Crispin wrote:
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 b
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.
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 c
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
sh
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
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
--
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 t
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.
pleas
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= capabili
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 por
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
Russ Allbery wrote:
>
> Ken Murchison <[EMAIL PROTECTED]> writes:
>
> > 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, fr
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 ser
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 a
Mark Crispin wrote:
>
> I note that there is an I-D, draft-kohn-news-article-00.txt, which
> addresses Usenet mail format in a compatible fashion without introducing
> the major incompatibilities that would be inflicted on other protocols
> (including IMAP) by adding raw, untagged UTF-8 to news
Chris,
Thanks for the input. I'd been hoping for a while that you'd comment
the NNTP SASL/STARTTLS stuff, especially reasons why your DSS draft died
on the vine. I'm going to forward your response to the nntpext mailing
list in the hope that it might help steer the discussion a little bit.
All
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
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 R
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=REFERENCE
Arnt Gulbrandsen wrote:
>
> Cyrus Daboo writes:
> > However, I will again voice my annoyance with the fact that the
> > THREAD=REFERENCES extension does any kind of grouping based on
> > subject.
>
> Seconded!
>
> THREAD=REFERENCES is its name, so why can't it THREAD based on
> REFERENCES? The
Mark Crispin wrote:
>
> On Thu, 10 Jan 2003, Timo Sirainen wrote:
> > Another thing I saw with UW, it
> > didn't group these messages together:
> > Subject: =?iso-8859-1?Q?foo?=
> > Subject: =?iso-8859-1?Q?RE=3A_foo?=
>
> Question for the list: should it?
FWIW, Cyrus does. This is because the
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
50 matches
Mail list logo
