Hi,
Say a mailbox has 1000 messages in it, and the highest UID is 1600. Which
is the correct response?
1 UID FETCH 1601:* FLAGS
1 OK FETCH completed.
or
1 UID FETCH 1601:* FLAGS
* 1000 FETCH (UID 1600 FLAGS (\Seen))
1 OK FETCH completed.
? Andy
--
Andreas Aardal Hanssen
--
-
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 correct response?
>
>1 UID FETCH 1601:* FLAGS
>1 OK FETCH completed.
>
>or
>
>1 UID FETCH 1601:* FLAGS
>* 1000 FETCH (UID 1600 FLAGS (\Seen))
>1 OK FETCH comp
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 correct response?
> >
> >1 UID FETCH 1601:* FLAGS
> >1 OK FETCH completed.
> >
> >or
> >
> >1 UID FETCH 1601:* FLAGS
> >* 1000 FETCH
On Fri, 31 May 2002, Alexey Melnikov wrote:
>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 correct response?
>> >1 UID FETCH 1601:* FLAGS
>> >1 OK FETCH completed.
>> >or
>> >1
> 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 correct response?
> >
> >1 UID FETCH 1601:* FLAGS
> >1 OK FETCH completed.
> >
> >or
> >
> >1 UID FETCH 1601:* FLAGS
> >* 1000 FETCH (UID 1600 FLAGS (\S
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 correct response?
> > >
> > >1 UID FETCH 1601:* FLAGS
> > >1 OK FETCH completed.
> > >
> > >or
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 correct response?
> > > >
> > > >1 UID FETCH 1601:* FLAGS
>
Gaël Roualland <[EMAIL PROTECTED]>
> Yes, "*" is translated for 1600, so that gives the range 1601:1600.
> But does that have sense ?
Sure.
> (general understanding is probably that the
> second sequence number must be larger or equal to the first one, but I
> can't find it in the RFC).
Precis
At 14:51 31/05/2002 +0200, you wrote:
>Gaël Roualland <[EMAIL PROTECTED]>
> > Yes, "*" is translated for 1600, so that gives the range 1601:1600.
> > But does that have sense ?
>
>Sure.
>
> > (general understanding is probably that the
> > second sequence number must be larger or equal to the firs
On Fri, 31 May 2002, Paul Smith wrote:
>At 14:51 31/05/2002 +0200, you wrote:
>>Gaël Roualland <[EMAIL PROTECTED]>
>> > Yes, "*" is translated for 1600, so that gives the range 1601:1600.
>> > But does that have sense ?
>>Sure.
>> > (general understanding is probably that the
>> > second sequence
On Fri, 31 May 2002, Paul Smith wrote:
> (It doesn't actually seem to explicitly say what '10:20' means either...
> (as far as I can see). It means 'messages 10 to 20 inclusive' (I hope...),
> but I can't see anywhere it says this it wouldn't be impossible for
> someone to interpret it to mean '2
There is no requirement in the protocol that max be higher than min in a message set.
So 1601:1600 is the same as 1600:1601, and thus the second response is correct.
Larry Osterman
> -Original Message-
> From: Gaël Roualland [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 31, 2002 5:3
On Fri, 31 May 2002, Larry Osterman wrote:
>There is no requirement in the protocol that max be higher than min in a
>message set. So 1601:1600 is the same as 1600:1601, and thus the second
>response is correct.
If this is correct, then courier-imap is wrong. I tested version 1.4.6
(most recent
Paul Smith <[EMAIL PROTECTED]>
> >Precisely. As far as the RFC says, "1:2" and "2:1" are equivalent.
>
> It doesn't say this.. (as far as I can see). It's open to interpretation
> from reading the RFC.
Exactly. ;)
It says a:b means all the messages with MSNs/UIDs between a and b,
inclusive. Th
Mark Crispin wrote:
> OK, I'm trying to digest all of this.
>
> It seems clear to me that TLS+AUTH=PLAIN will be a solution, and will be
> required of all IMAP server implementations. I have not seen any
> objection to either "TLS+AUTH=PLAIN is a solution" or "TLS+AUTH=PLAIN is
> required of all
> I therefore recommend to the group that we declare that:
> . *the* solution is TLS+AUTH=PLAIN
> . TLS+AUTH=PLAIN is mandatory to implement on both client and server
> . the problem is solved
> and abandon alternatives.
Okay, I'm not going to fight this particular battle. I do want to
go on r
Actually I'm pretty certain that (I think) pine will generate message
sets in the form of a:b where b>a. I remember that it surprised me when
I first saw it, so I quickly changed the server to handle that case.
If it wasn't pine, it was one of the other common MUA's.
Larry Osterman
-Ori
On Fri, 31 May 2002, Larry Osterman wrote:
>Actually I'm pretty certain that (I think) pine will generate message
>sets in the form of a:b where b>a. I remember that it surprised me when
>I first saw it, so I quickly changed the server to handle that case.
>If it wasn't pine, it was one of the ot
As many people have already said, a UID sequence of max+1:* is equivalent to
*, the maximum UID. The presumption here is that max==* but the client does
not know that, which is something that can happen with a UID client.
In the case of a message sequence number, max+1:* is a syntax error. Unli
On Fri, 31 May 2002 09:20:44 -0700, Larry Osterman wrote:
> Actually I'm pretty certain that (I think) pine will generate message
> sets in the form of a:b where b>a. I remember that it surprised me when
> I first saw it, so I quickly changed the server to handle that case.
I'm pretty sure that
Mark Crispin <[EMAIL PROTECTED]>
> Courier violates IMAP in multiple ways.
Could you elaborate?
--Arnt
On Fri, 31 May 2002, Mark Crispin wrote:
>As many people have already said, a UID sequence of max+1:* is equivalent
>to *, the maximum UID. The presumption here is that max==* but the
>client does not know that, which is something that can happen with a UID
>client. In the case of a message seque
On Fri, 31 May 2002 20:27:16 +0200 (CEST), Andreas Aardal Hanssen wrote:
> >Courier violates IMAP in multiple ways. I long ago gave up any hope of
> >getting its author to fix these bugs; he has basically said that Courier
> >deliberately violates IMAP as his protest against the protocol.
> We'll
begin quotation by Mark Crispin on 2002/5/30 18:25 -0700:
> I therefore recommend to the group that we declare that:
> . *the* solution is TLS+AUTH=PLAIN
> . TLS+AUTH=PLAIN is mandatory to implement on both client and server
> . the problem is solved
> and abandon alternatives.
This is accept
On Fri, 31 May 2002, Mark Crispin wrote:
>On Fri, 31 May 2002 20:27:16 +0200 (CEST), Andreas Aardal Hanssen wrote:
>> >Courier violates IMAP in multiple ways. I long ago gave up any hope of
>> >getting its author to fix these bugs; he has basically said that Courier
>> >deliberately violates IMAP
On Fri, 31 May 2002 22:09:11 +0200 (CEST), Andreas Aardal Hanssen wrote:
> *sigh*, and it's not just Sam, it's the whole community. What is a good
> implementation, is Cyrus better?
Among freeware servers:
Cyrus is an excellent implementation. There are a couple of minor issues in
Cyrus (as I r
On Fri, 31 May 2002, Chris Newman wrote:
> > I therefore recommend to the group that we declare that:
> > . *the* solution is TLS+AUTH=PLAIN
> > . TLS+AUTH=PLAIN is mandatory to implement on both client and server
> > . the problem is solved
> > and abandon alternatives.
> This is acceptable to
Assuming that we set "TLS+AUTH=PLAIN" as the "mandatory to implement"
answer for IESG, I have two questions:
1) Can a compliant server implementation be built without TLS support?
In particular, UW's pre-built imapd binaries do *NOT* have TLS support
because our lawyers' interpretation of US law
> Assuming that we set "TLS+AUTH=PLAIN" as the "mandatory to implement"
> answer for IESG, I have two questions:
> 1) Can a compliant server implementation be built without TLS support?
> In particular, UW's pre-built imapd binaries do *NOT* have TLS support
> because our lawyers' interpretation
> On Fri, 31 May 2002, Chris Newman wrote:
> > > I therefore recommend to the group that we declare that:
> > > . *the* solution is TLS+AUTH=PLAIN
> > > . TLS+AUTH=PLAIN is mandatory to implement on both client and server
> > > . the problem is solved
> > > and abandon alternatives.
> > This is
Okay. I want off. I might rejoin from another address cuz I wanna
implement a spiffy little imap server. But, for the mean time, I want off.
So.. how do I get off? (no bad jokes please)
--Jessica
--
Jessica L. Blank, Systems Adm
On Fri, 2002-05-31 at 22:01, Jessica Blank wrote:
> Okay. I want off. I might rejoin from another address cuz I wanna
> implement a spiffy little imap server. But, for the mean time, I want off.
> So.. how do I get off? (no bad jokes please)
>
>
32 matches
Mail list logo
