three confirmed Courier bugs
Mark Crispin
server which identifies itself as:
* OK Courier-IMAP ready. Copyright 1998-2002 Double Precision, Inc. See COPYING for distribution information.
These bugs have been reported on multiple occasions. I do not care what
the author of Courier (or his groupies) thinks about me, other client
authors, or the IMAP specification. I care that about compliance with the
IMAP specification and interoperability between IMAP clients and servers.
These are not esoteric problems. These bugs cause real problems for
IMAP clients.
Bug 1: Does not parse IMAP atoms correctly
Accepts in atoms the following characters which are not valid in atoms:
"(", ")", "*", "%"
Rejects in atoms the following characters which are valid in atoms:
"}"
From RFC 2065, "Formal Syntax":
atom ::= 1*ATOM_CHAR
ATOM_CHAR ::= <any CHAR except atom_specials>
atom_specials ::= "(" / ")" / "{" / SPACE / CTL / list_wildcards /
quoted_specials
list_wildcards ::= "%" / "*"
quoted_specials ::= <"> / "\"
Bug 2: Does not parse number ranges (n:m) correctly
If n is greater than m, it treats the range as no messages at all. The
specification requires an inclusive range.
This is particularly important in UID clients using "*" for m, which may
not know that n is larger. Not returning anything to a FETCH n:* implies
that there are no messages in the mailbox.
Bug 3: Does not implement THREAD=ORDEREDSUBJECT correctly
Does not sort the threads by the sent date of the first message in the
thread as required by the specification; instead, the threads are sorted
by subject.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Sam
Hash: SHA1
In article <Pine.LNX.4.50.02060...@shiva0.cac.washington.edu>,
Mark Crispin <m...@CAC.Washington.EDU> writes:
> Bug 1: Does not parse IMAP atoms correctly
>
> Accepts in atoms the following characters which are not valid in atoms:
> "(", ")", "*", "%"
A bug/design flaw in the protocol specification.
> Bug 2: Does not parse number ranges (n:m) correctly
>
> If n is greater than m, it treats the range as no messages at all. The
That's right, Einstein. That's what a null set contains. A range with a
starting position greater than the ending position is a null range. Kids
learn this stuff in grade school mathematics, I believe.
> specification requires an inclusive range.
An inclusive null range is still a null range.
> Bug 3: Does not implement THREAD=ORDEREDSUBJECT correctly
>
> Does not sort the threads by the sent date of the first message in the
> thread as required by the specification; instead, the threads are sorted
> by subject.
THREAD=ORDEREDSUBJECT is not defined by any RFC, it's still an experimental
draft only, subject to change.
Yawn.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE8/kwT3ejdWUS0ltARAodEAJ0Q82ZWJ2jJ/Egz/W0wFRVNatqHiACeLUrl
HF8J7fr8/GiyCCBSYVjMtk4=
=BNQR
-----END PGP SIGNATURE-----
Simon Josefsson
> Bug 1: Does not parse IMAP atoms correctly
>
> Accepts in atoms the following characters which are not valid in atoms:
> "(", ")", "*", "%"
> Rejects in atoms the following characters which are valid in atoms:
> "}"
>
> From RFC 2065, "Formal Syntax":
> atom ::= 1*ATOM_CHAR
> ATOM_CHAR ::= <any CHAR except atom_specials>
> atom_specials ::= "(" / ")" / "{" / SPACE / CTL / list_wildcards /
> quoted_specials
> list_wildcards ::= "%" / "*"
> quoted_specials ::= <"> / "\"
Do you have a protocol snippet to illustrate this bug? I don't
understand where this causes problems.
Courier isn't the only buggy server, I have found protocol errors in
several servers -- http://josefsson.org/nnimap/buggy-imap-servers.html
Sam
Hash: SHA1
In article <courier.3CFE...@ny.email-scan.com>,
Sam <s...@email-scan.com> writes:
> In article <Pine.LNX.4.50.02060...@shiva0.cac.washington.edu>,
> Mark Crispin <m...@CAC.Washington.EDU> writes:
>
>> Bug 3: Does not implement THREAD=ORDEREDSUBJECT correctly
>>
>> Does not sort the threads by the sent date of the first message in the
>> thread as required by the specification; instead, the threads are sorted
>> by subject.
>
> THREAD=ORDEREDSUBJECT is not defined by any RFC, it's still an experimental
> draft only, subject to change.
>
> Yawn.
Oh, just for the hell of it, I looked up what happened with the
experimental THREAD extension. And, the threads are definitely sorted by
the sent date.
a thread orderedsubject iso-8859-1 all
* THREAD (351 420 709 855) ...
... (262 177 182 206) ...
Picking the first thread I spot with messages not in numerical order, and
what do I see?
a fetch 262 (body[header.fields(date)])
* 262 FETCH (BODY[HEADER.FIELDS ("date")] {41}
Date: Wed, 29 May 2002 22:08:59 -0500
)
a OK FETCH completed.
a fetch 177 (body[header.fields(date)])
* 177 FETCH (BODY[HEADER.FIELDS ("date")] {41}
Date: Thu, 30 May 2002 14:55:32 +0200
)
a OK FETCH completed.
Pulling the source code confirms the logic. That module wasn't touched in
two years, so it's not clear to me where's the beef here.
You know, I should've followed my initial instinct, and instead of being
diplomatic in my initial response, I should've stated that you were full of
shit. As always. And I would've been right. That's what I thought at
first too, since I knew that I did everything correctly. But, I thought,
perhaps something had changed in the intervening years, since the last time
I looked at the draft, that I didn't know about. But no, that wasn't the
case. ORDEREDSUBJECT's definition hasn't changed at all, unfortunately.
It would've been nice to have it rewritten with a little bit more clarity,
but we aren't so lucky, I suppose. It's still as confusing, redundant, and
nonsensical as it always was.
So, to compensate for my missed opportunity to flame Crispin, when I had a
good excuse for doing so, I'll make up for it by flaming the draft.
Reviewing the whole mess brought back fond memories. It was always amazing
how much obfuscation, plain nonsense, and self-contradictory claims, was
possible to cram into a single paragraph:
ORDEREDSUBJECT
The ORDEREDSUBJECT threading algorithm is also referred to as
"poor man's threading." The searched messages are sorted by
subject and then by the sent date.
Well, if you first sort the messages by the subject, and then you sort all
the messages by the sent date, then the first sort wasn't needed at all,
was it? Since you'll re-sort the whole thing by sent date anyway, you
don't need to do the first sort. But, I'm fairly sure this meant to state
that the subject is the primary sort key, and the sent date is a secondary
sort key, so that's going to be it. That's probably the likeliest meaning
of that.
... The messages are then split
into separate threads, with each thread containing messages
with the same extracted subject text ...
Well, I just had to quote the sole logical occupant of the otherwise
illogical paragraph, just so I wouldn't be accused later of selectively
editing out this stuf. Praise gawd, this sentence mostly makes sense...
... Finally, the threads are
sorted by the sent date of the first message in the thread.
And this sentence definitely wins the prize for Gobbledygook Of The
Year[tm], because it manages to not make any sense in two different ways.
And that's not an easy accomplishment. First-ly <cough> each thread is
already sorted by the sent date anyway, due to sent date being the
secondary sort key in the first place. Second-ly <cough> "sent date of the
first message in the thread" is obviously not a property of each message in
the thread, so saying that it should be used as a sort key, when sorting
each thread, makes no sense whatsoever. So, the double-whammy is that, for
starters, the threads are already sorted by the sent date of each message
in the thread, and the specification of the sort key is completely
non-sensical.
So, who knows what that is all about. Certainly not me. The entire
definition of ORDEREDSUBJECT threading consists of this lone,
contradictory, and confusing paragraph (which, sadly, doesn't differ from
the typical logic factor of your drivel). Perhaps others who have all the
necessary secret decoder rings can make sense of all that. I don't have
any secret decoder rings, I only have to go with what I read. If history's
a teacher, it'll probably take two or three revisions before any of this
reaches a state where most people can clearly understand it. I'll worry
about it then. Right now, as far as I'm concerned, everything's working
the way it should work, or at least the way it reads.
So that's my sermon for today. I thought about sprucing it up with my
legendary humor, and wit. But that would've taken up too much time, and
this particular Crispinrant wasn't worth it. I'll save the yuks for next
time. Promise.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE8/ln43ejdWUS0ltARAgpkAJ0b25O+u6tik6RutadBIkLq1tzrfACgkXlK
6phJRZ7Aa8osenuPe5Svlk0=
=8B8W
-----END PGP SIGNATURE-----
Mark Crispin
atom. However, a LOGIN command which attempts to transmit it as an atom
will result in:
* OK Courier-IMAP ready. Copyright 1998-2002 Double Precision, Inc. See COPYING for distribution information.
. login foo bar}zap
. NO Error in IMAP command received by server.
Whether or not } should be an atom_special is besides the point. The
specification says that it is not an atom_special, therefore it is
permitted to have an atom containing this character.
Mark Crispin
> A bug/design flaw in the protocol specification.
That is besides the point. Fix your server to comply with the protocol
specification.
> That's right, Einstein. That's what a null set contains. A range with a
> starting position greater than the ending position is a null range. Kids
> learn this stuff in grade school mathematics, I believe.
There is nothing in the protocol specification that says that one value is
a "starting position" and the other is an "ending position". The exact
wording in the specification is "delimits between two numbers inclusive."
Courier's implementation breaks UID clients (no, not Pine) which send n:*
where n is one greater than the previous maximum UID. If n is larger than
the UID for the last message in the mailbox, Courier returns no data.
The correct response in this case is to return data for the last message.
Courier's incorrect response is interpreted by these UID clients as
indicating that there are no messages in the mailbox.
> THREAD=ORDEREDSUBJECT is not defined by any RFC, it's still an experimental
> draft only, subject to change.
The THREAD specification is a document of the IETF IMAP Extensions Working
Group, which you have made no effort to participate in. There is no
likelihood that the semantics of THREAD=ORDEREDSUBJECT are going to be
changed, as the only matter left under discussion is the semantics of
collation of non-ASCII strings.
Courier's implementation of THREAD=ORDEREDSUBJECT is incompatible from
every other implementation. There is no need for this incompatibility.
There is no need for any of Courier's other incompatibilities (including
the two discussed above) either.
I don't care if you don't like me or the IMAP specification. However, you
owe it to your users to fix your bugs that cause incompatibilities and
interoperability failures with other IMAP implementations.
Sam
Hash: SHA1
In article <Pine.LNX.4.50.020605...@shiva0.cac.washington.edu>,
Mark Crispin <m...@CAC.Washington.EDU> writes:
> Consider a user who has a password of bar}zap. This can be sent as an
> atom. However, a LOGIN command which attempts to transmit it as an atom
> will result in:
>
> * OK Courier-IMAP ready. Copyright 1998-2002 Double Precision, Inc. See COPYING for distribution information.
> . login foo bar}zap
> . NO Error in IMAP command received by server.
>
> Whether or not } should be an atom_special is besides the point. The
> specification says that it is not an atom_special, therefore it is
> permitted to have an atom containing this character.
The specification is wrong.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE8/mCW3ejdWUS0ltARAgD2AJ470Uuyfr0PB0vlY9PPg982LxJifwCePFS9
tAzVDFq8w0TGxSVSaGMZBUg=
=aizQ
-----END PGP SIGNATURE-----
Sam
Hash: SHA1
In article <Pine.LNX.4.50.020605...@shiva0.cac.washington.edu>,
Mark Crispin <m...@CAC.Washington.EDU> writes:
> On Wed, 5 Jun 2002, Sam wrote:
>> A bug/design flaw in the protocol specification.
>
> That is besides the point.
No that's very much the point. A bug, and especially a design flaw, needs
to be fixed. To blindly follow a broken, flawed, design is illogical, and
stupid. You want to keep doing the same stupid thing, all over and over
again? Fine, it's your job now. You can have it. I'll do something else
instead.
> Fix your server to comply with the protocol
> specification.
The server complies with the protocol specification, without complying with
its stupid design flaws.
>
>> That's right, Einstein. That's what a null set contains. A range with a
>> starting position greater than the ending position is a null range. Kids
>> learn this stuff in grade school mathematics, I believe.
>
> There is nothing in the protocol specification that says that one value is
> a "starting position" and the other is an "ending position".
That's how a numerical range is defined: starting value and and ending
value. Again, review your grade school Mathematics course book, for
additional information.
When the rules of mathematics are changed to show that 4 is less than 3,
then I'll make corresponding changes to my code, but not until then.
> Courier's implementation breaks UID clients (no, not Pine) which send n:*
> where n is one greater than the previous maximum UID.
Clients that do that are already broken, by the time they've ever gotten
this far. I do not place much priority on accomodating broken clients. If
you want to do that yourself, fine, that's your call, and a privilege. But
it is not my privilege either to waste the rest of my life chasing after
every bug in every broken client.
> If n is larger than
> the UID for the last message in the mailbox, Courier returns no data.
> The correct response in this case is to return data for the last message.
It's not. A null set is a null set. Pretending that a null set isn't a
null set is absurd.
>> THREAD=ORDEREDSUBJECT is not defined by any RFC, it's still an experimental
>> draft only, subject to change.
>
> The THREAD specification is a document of the IETF IMAP Extensions Working
Am I supposed to be impressed, or something? Just want to make sure I have
the scenario right.
> Group, which you have made no effort to participate in.
Thanks, but I'd rather watch the paint dry, on my porch. IETF is good at
formalizing de-factor standards, but as far as developing and producing new
standards go, the IETF is a major waste of time.
> There is no
> likelihood that the semantics of THREAD=ORDEREDSUBJECT are going to be
> changed, as the only matter left under discussion is the semantics of
> collation of non-ASCII strings.
>
> Courier's implementation of THREAD=ORDEREDSUBJECT is incompatible from
> every other implementation.
Every implementation is incompatible with every other implementation, by
the virtue of the fact that there is no firm, stable, specification.
Especially when the specification is still vague, and unclear on a number
of points. But that's been covered elsewhere. In any case, if the
collation order is changed, then all the vaporware implementations will
suddenly become incompatible with each other either anyway. In the
immortal words of Bugs Bunny: biiiiiiiig deal...
> There is no need for this incompatibility.
>
> There is no need for any of Courier's other incompatibilities (including
> the two discussed above) either.
The only incompatibles present at this time are incompatibilities with
protocol bugs, and design flaws. I place no priority whatsoever on trying
to reimplement all the design flaws, and protocol bugs. Doing so only
encourages further sloppy coding practices and implementations in other
products.
> I don't care if you don't like me or the IMAP specification.
I don't care if you do not like my server either. Not unless, of course,
there's some humor value in it.
> However, you
> owe it to your users to fix your bugs that cause incompatibilities and
> interoperability failures with other IMAP implementations.
I might owe something to my users, but since you're not one of them you
really are no position to demand anything, no matter who you think you are.
Neither are you in any position to pass judgment on something that you
really do not have much first hand knowledge about. You might still choose
to do so, since everyone is entitled to a privilege of being able to
blather without a clue. Including you.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE8/mbr3ejdWUS0ltARAnGCAJ4wU0IXaIwliZH8Ip7zNlVk0vVJ5wCcDaQH
heTlEL2pyONh3KTb+6damfw=
=l8E2
-----END PGP SIGNATURE-----
Simon Josefsson
>>
>>> That's right, Einstein. That's what a null set contains. A range with a
>>> starting position greater than the ending position is a null range. Kids
>>> learn this stuff in grade school mathematics, I believe.
>>
>> There is nothing in the protocol specification that says that one value is
>> a "starting position" and the other is an "ending position".
>
> That's how a numerical range is defined: starting value and and ending
> value. Again, review your grade school Mathematics course book, for
> additional information.
Trying to be a bit constructive, and since the IMAP spec is up for
last call: How about clarifying the wording that there is no sorting
required in a article number range? Perhaps even illustrate it with a
weird example such as "*,5:3,8,*,9:11". Considering that at least 5
different servers implement message ranges incorrectly, perhaps the
source of the confusion is the specification.
IMHO the word "range" should not be used in this context. "set" is
better.
Mark Crispin
> experimental THREAD extension. And, the threads are definitely sorted by
> the sent date.
> a thread orderedsubject iso-8859-1 all
> * THREAD (351 420 709 855) ...
> ... (262 177 182 206) ...
>
> Picking the first thread I spot with messages not in numerical order, and
> what do I see?
Yes, the messages within a thread are sorted by the sent date. However,
the threads themselves are not sorted by the sent date of the first
message in the thread. Read the specification for ORDEREDSUBJECT
carefully, specifically what comes after "Finally":
[...] The searched messages are sorted by
subject and then by the sent date. The messages are then split
into separate threads, with each thread containing messages
with the same extracted subject text. Finally, the threads are
sorted by the sent date of the first message in the thread.
Courier does not do the final step, leaving the threads sorted by the
Sam
Hash: SHA1
In article <ilu1ybl...@latte.josefsson.org>,
Simon Josefsson <simon...@josefsson.org> writes:
> weird example such as "*,5:3,8,*,9:11". Considering that at least 5
> different servers implement message ranges incorrectly, perhaps the
> source of the confusion is the specification.
The gentleman wins a cigar.
> Trying to be a bit constructive, and since the IMAP spec is up for
> last call: How about clarifying the wording that there is no sorting
> required in a article number range? Perhaps even illustrate it with a
And what exactly is going to be gained by that? Why have two different
ways to say the same thing? What possible value is there in specifying a
bass-ackwards range? n:*? Well, why don't YOU (for some general values of
"you") learn how to code properly. If you know what you're doing, you
don't need "FETCH n:*" to check for new mail. This is just a stupid way to
do something when you don't know how to do this right. Somehow, plenty of
people have figured out how to do this right, without feeling an urgent
need to list message IDs backwards, or throw "n:*" at the server, and
figure out what comes back.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE8/npP3ejdWUS0ltARArCcAJ9VPpQaUgNrtJqrCLQ6/qsfkas9vACaA5Ke
b+GoUot+iglWlNkXXXoUM+I=
=4lsv
-----END PGP SIGNATURE-----
Mark Crispin
> Trying to be a bit constructive, and since the IMAP spec is up for
> last call: How about clarifying the wording that there is no sorting
> required in a article number range?
Already done.
> IMHO the word "range" should not be used in this context. "set" is
> better.
Unfortunately, "set" means something else. However, "range" is not used
in the Formal Syntax for precisely this reason.
Mark Crispin
> The server complies with the protocol specification, without complying with
> its stupid design flaws.
This is
> > There is nothing in the protocol specification that says that one value is
> > a "starting position" and the other is an "ending position".
> That's how a numerical range is defined: starting value and and ending
> value. Again, review your grade school Mathematics course book, for
> additional information.
A grade school Mathematics course book is not normative for the IMAP
protocol specification or, as far as I know, any other protocol
specification. Nowhere in the IMAP specification does it say that n:m
syntax refers to "starting value and ending value".
The IMAP specification says "between two numbers inclusive".
> > Courier's implementation breaks UID clients (no, not Pine) which send n:*
> > where n is one greater than the previous maximum UID.
> Clients that do that are already broken, by the time they've ever gotten
> this far.
The other client and server implementors do not agree with you.
> I might owe something to my users, but since you're not one of them you
> really are no position to demand anything, no matter who you think you are.
Most unfortunately, I have to communicate with the broken Courier IMAP
server in order to retrieve my invoices and payment records from my ISP.
So I *am* one of your users.
I want to retrieve them to an embedded device, but Courier's bugs preclude
interoperability with that device's IMAP client. I am obliged to access
that server with Pine (which, if one is careful, can work with Courier),
transfer the messages to a UW or Cyrus server, and then transfer them to
the embedded device.
Sam
Hash: SHA1
In article <Pine.LNX.4.50.020605...@shiva0.cac.washington.edu>,
Mark Crispin <m...@CAC.Washington.EDU> writes:
> On Wed, 5 Jun 2002, Sam wrote:
>> Oh, just for the hell of it, I looked up what happened with the
>> experimental THREAD extension. And, the threads are definitely sorted by
>> the sent date.
>> a thread orderedsubject iso-8859-1 all
>> * THREAD (351 420 709 855) ...
>> ... (262 177 182 206) ...
>>
>> Picking the first thread I spot with messages not in numerical order, and
>> what do I see?
>
> Yes, the messages within a thread are sorted by the sent date. However,
> the threads themselves are not sorted by the sent date of the first
> message in the thread. Read the specification for ORDEREDSUBJECT
> carefully, specifically what comes after "Finally":
Read the rest of my post, and fix your document. The part after "finally"
is ambiguous (in addition to the part before it), with more than one
possible way to interpret it. Next time you feel the urgent need to
blather your head off, stop and think if perhaps your own scribblings need
to be fixed so they don't require a secret decoder ring.
> [...] The searched messages are sorted by
> subject and then by the sent date. The messages are then split
> into separate threads, with each thread containing messages
> with the same extracted subject text. Finally, the threads are
> sorted by the sent date of the first message in the thread.
>
> Courier does not do the final step, leaving the threads sorted by the
> subject.
No, you need to bone up on your English (funny that). The threads are
sorted by sent date (you pick a thread, and you'll find that's how the
thread is sorted by), it's the collection of threads that you imply should
be resorted by sent date.
But then, this opens up another bunch of problems:
...
All servers and disconnected clients MUST use exactly this algorithm
when threading. Otherwise there is potential for a user to get
inconsistent results based on whether they are running in connected
or disconnected IMAP mode.
...
Well, that's the end of that, then. Nice try, but no cigar. Plenty of
messages will now have the same sent date (think cron jobs), therefore you
can throw this pie-in-the-sky idea right out of the window, because you now
have an ambiguous final ordering anyway.
That's why, when faced with two possible interpretation of that whole
paragraph, the interpretation where the sort order referred to the threads'
internal sort order made more sense. The collection of threads, at least,
used a clear, unambiguous, subject ordering so far. Therefore, the most
logical intepretation is to conclude that this is a reference to each
thread's internal sort order. Which will still be ambiguous but at least
the magnitude of the mess is smaller, and the thread index itself is in an
unambiguous order.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE8/n5W3ejdWUS0ltARAvxEAJ47HKqbMIrNGH6FxR7XCV6zDwf8mQCfWvqt
VAxKhCYxPBgi0TC/U8z1TkU=
=2aPo
-----END PGP SIGNATURE-----
Sam
Hash: SHA1
In article <Pine.LNX.4.50.020605...@shiva0.cac.washington.edu>,
Mark Crispin <m...@CAC.Washington.EDU> writes:
> On Wed, 5 Jun 2002, Sam wrote:
>> The server complies with the protocol specification, without complying with
>> its stupid design flaws.
>
> This is
>
>> > There is nothing in the protocol specification that says that one value is
>> > a "starting position" and the other is an "ending position".
>> That's how a numerical range is defined: starting value and and ending
>> value. Again, review your grade school Mathematics course book, for
>> additional information.
>
> A grade school Mathematics course book is not normative for the IMAP
> protocol specification or, as far as I know, any other protocol
> specification.
A good grasp on mathematics is an absolute requirement for implementing any
kind of a computing procedure, or an algorithm. Otherwise, you'll have a
real problem figuring out whether you want to use the ++ or the --
operator, in each case, won't you?
This just has to be the loopiest thing I've heard in quite some time. You
know, if I were to use that as sig material, people would DEFINITELY get
the wrong idea. No, just think about it. You walk off the street, not
knowing anything about this, and just see this sig quote on some random
Usenet post. What would you think the original writer intended to say?
Well, you're in luck because I'm not that big on sigs. If I were, you'd
never hear the end of it.
> Nowhere in the IMAP specification does it say that n:m
> syntax refers to "starting value and ending value".
Neither does it say that n:m refers to the "ending value and a starting
value" either. So, people that prefer to think logically will therefore
conclude that n:m refers to a numerically increasing range, because logic
tends to be forward-thinking (in a metaphysical sort of way), and logic
> The IMAP specification says "between two numbers inclusive".
"inclusive" doesn't tell you anything useful, in this case. An "inclusive"
increasing numerical sequence, and an "inclusive" decreasing sequence are
two completely different thinks, so a mere reference to "inclusive" does
not disambiguate anything.
>> > Courier's implementation breaks UID clients (no, not Pine) which send n:*
>> > where n is one greater than the previous maximum UID.
>> Clients that do that are already broken, by the time they've ever gotten
>> this far.
>
> The other client and server implementors do not agree with you.
Well, I'm sure there aren't any client or server implementators out there
who would admit to the fact that their code is broken. However, it doesn't
change the fact that it is.
>> I might owe something to my users, but since you're not one of them you
>> really are no position to demand anything, no matter who you think you are.
>
> Most unfortunately, I have to communicate with the broken Courier IMAP
> server in order to retrieve my invoices and payment records from my ISP.
> So I *am* one of your users.
Well, _THAT_ definitely has to be the funniest thing I've read in at least
a couple of years.
But don't worry about it. According to you, maildir-based IMAP service is
horribly inefficient. After all, that's what you've been saying for years.
Some blather to that effect can still be found in UW-IMAP's source code, I
believe. Not that I care, of course, I'm just pointing out a relevant
fact. And if you're going to deny that, I'll just go back to Google and
prove that as well.
So... you really don't have anything to worry about, since any day now your
ISP is going to dump that horribly inefficient, and slow, server, and go
back to using the fast, reliable UW-IMAP server. Or Cyrus. Or DK-IMAP.
Don't worry, I'm confident that you won't have to suffer such an indignity
for much longer.
> I want to retrieve them to an embedded device, but Courier's bugs preclude
> interoperability with that device's IMAP client. I am obliged to access
> that server with Pine (which, if one is careful, can work with Courier),
> transfer the messages to a UW or Cyrus server, and then transfer them to
> the embedded device.
Well, one rule I recommend that everyone should follow is to carefully
consider anyone that you choose to piss on. Make sure that they will never
ever be in a position to piss back on you.
I follow that rule myself. Really, I do. This is actually not the rule
itself, only a sanitized version. The real rule uses a somewhat more crude
choice of words. But I have an image, and a dignified reputation to
maintain, so I won't use it. (STOP, read the other thread before having
another cow, g'd-emnit, do I have to spell out everything, every time?)
I'm dying to know if that ISP uses qmail too. That would definitely be the
icing on the cake. I think I can make a fairly good guess what ISP this is
(there aren't that many, after a brief process of elimination and
enumeration). If I'm right, I know that their mail transport is
qmail-ldap, baaaa-ha-ha...
If I'm right, and if the parties concerned are lurking in here, I thought
that I should let y'all know that I've set up a script on the
@courier-mta.com mailbox that automatically "deletes" the headers from any
mail that includes a copy of any missive received by customer support, that
relies on the author's stature and claimed credentials in badmouthing their
choice of server software...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE8/oe83ejdWUS0ltARAmPYAJ9BtSO47X9ymJ9VBEJyji9P/yw0eQCgl5ND
0pyiM7tH2bhGqWZeH85wrWg=
=F7wx
-----END PGP SIGNATURE-----
DINH Viet Hoa
> > specification says that it is not an atom_special, therefore it is
> > permitted to have an atom containing this character.
>
> The specification is wrong.
The specification is not as wrong as you are saying, just that
it is the choice of the author of the specification.
Whether it is a good or a bad choice, if you refer to a specification, you
have to follow it, unless you claim your server explicitely as
non-IMAP compliant.
--
DINH V. Hoa,
libEtPan! - a mail library - http://libetpan.sourceforge.net
Sam
Hash: SHA1
In article <etPan.3cff3940...@paralaplage.irisa.fr>,
DINH Viet Hoa <dinh-coeur.viet-fle...@free-sourire2.fr> writes:
>> > Whether or not } should be an atom_special is besides the point. The
>> > specification says that it is not an atom_special, therefore it is
>> > permitted to have an atom containing this character.
>>
>> The specification is wrong.
>
> The specification is not as wrong as you are saying, just that
> it is the choice of the author of the specification.
If someone made a bad choice, I am not obligated to follow it.
> Whether it is a good or a bad choice, if you refer to a specification, you
> have to follow it, unless you claim your server explicitely as
> non-IMAP compliant.
Look: everyone in front of you is jumping off a cliff. It's your turn now.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE8/2ht3ejdWUS0ltARAr+8AJ0XgBQzx4u6E5yWRIq/1TK6uQNoRQCeJv71
AkBRpd6G6nLrnljpn35cfDY=
=xEkk
-----END PGP SIGNATURE-----
Mark Crispin
> The specification is not as wrong as you are saying, just that
> it is the choice of the author of the specification.
It wasn't just a choice. It was explicit design that atom_specials would
include only those characters that MUST be atom_specials. To wit:
1) "(" is in atom_specials to distinguish from a start of a parenthesized
list. There are cases where either an atom or a parenthesized list can
appear.
2) ")" is in atom_specials to distinguish from an end of a parenthesized
list. Atoms can occur within a parenthesized list.
3) "{" is in atom_specials to distinguish from a literal size count. There
are cases where either an atom or a literal (or a quoted string) can
appear.
4) SPACE is in atom_specials because it is used as a delimiter between
objects including atoms.
5) CTL is in atom_specials because these are non-graphical characters.
6) list_wildcards is in atom_specials in order to disallow unquoted
wildcards in mailbox names (except in the LIST and LSUB commands, where
wildcards are appropriate).
7) quoted_specials is in atom_specials to distinguish from a quoted
string. There are cases where either an atom or a quoted string (or a
literal) can appear. This also enables the special naming of system flags
vs. keyword flags.
There is no reason for "}" to be in atom_specials. "}" can be part of an
atom without ambiguity with any other IMAP syntax. {23} can not be an
atom, because it is a literal size count, but 23} can be.
IMAP syntax is not decided by cosmetics (e.g. arguments such as "{ is
special so } should be"), nor IMAP syntax decided by anything not
explicitly declared as normative by the IMAP specification.
> Whether it is a good or a bad choice, if you refer to a specification, you
> have to follow it, unless you claim your server explicitely as
> non-IMAP compliant.
I agree. Failure to follow a specification, even those parts that you
feel are mistakes, is harmful to everybody. This lesson has been learned,
painfully, many times in the past 30 years.
If one feels that there is a mistake in a specification, the proper way is
to address it in the standards body for that specification. Disregarding
a portion of the specification as a "mistake", and disparaging the
standards body as "a waste of time", is cowboy behavior.
Sam
Hash: SHA1
In article <Pine.LNX.4.50.020606...@shiva0.cac.washington.edu>,
Mark Crispin <m...@CAC.Washington.EDU> writes:
> If one feels that there is a mistake in a specification, the proper way is
> to address it in the standards body for that specification.
Left sock, meet my right sock. Right sock, meet my left sock. Now that
we know each other, the show is on.
> Disregarding
> a portion of the specification as a "mistake", and disparaging the
> standards body as "a waste of time", is cowboy behavior.
That was a nice show, <clap> <clap>. The peanut gallery is impressed.
For all those sitting in the back row: this is a crude, slightly subtle,
attempt to shuffle off all the pesky troublemakers into a small closet, and
out of the public view. On they're on your own turf, cousin Billy-Bob, and
his brass knuckles will "fix" the problem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE8/3M93ejdWUS0ltARAm19AJ9Ny1b3zlsLmQCDr95KltuUTKaHnwCdFiCu
PlBQ7nZ4WAW+66/YhhlQDIk=
=n5HP
-----END PGP SIGNATURE-----
DINH Viet Hoa
> > it is the choice of the author of the specification.
>
> If someone made a bad choice, I am not obligated to follow it.
I remember that when I was implementing this part, I also wondered why '}'
was missing but Mark gave me the same answer.
I found *no* problems in the justification of Mark Crispin's
choice.
And I really see nothing difficult with the problem of '}' and no really
additionnal cost in performance.
It seems that you are the only one to complain about the
specification of IMAP protocol. All the grammar seems right to me.
I found no ambiguity.
--
DINH V. Hoa,
libEtPan! - a mail library - http://libetpan.sourceforge.net
"Il y a anguille sous roche"
Sam
Hash: SHA1
In article <etPan.3cff7ca8.6b8b4567.712e@homer>,
DINH Viet Hoa <dinh-coeur.viet-fle...@free-sourire2.fr> writes:
> It seems that you are the only one to complain about the
> specification of IMAP protocol.
... in public.
> All the grammar seems right to me.
> I found no ambiguity.
There aren't really that many people to start with, who might be in a
position where they might complain. And most people would choose simply to
plow ahead, because they would deem -- reasonably -- that it would be a
waste of time. And I tend to agree, with one exception: if someone starts
dissin' in public, then I'm not going to remain seated in the peanut
gallery. I'll be happy to contribute my own thoughts on the subject, and I
could prove them too. If someone wants to dish things out, they'll just
have to take some of their own.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE8/4bZ3ejdWUS0ltARAuHbAKCOMyJIRgcWMglr0ZMaZDPQoZsktgCcCvbn
1OrBY0f6Zd7bHImvVetSfJs=
=OVBk
-----END PGP SIGNATURE-----
T.Rash
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In article <etPan.3cff3940...@paralaplage.irisa.fr>,
> DINH Viet Hoa <dinh-coeur.viet-fle...@free-sourire2.fr>
> writes:
>
>> Whether it is a good or a bad choice, if you refer to a specification,
>> you have to follow it, unless you claim your server explicitely as
>> non-IMAP compliant.
>
> Look: everyone in front of you is jumping off a cliff. It's your turn
> now.
>
He may jump or he may stay back. The only thing he can't do is stepping
into a rabbit burrow and claim to be a cliff jumper.
BTW, I'm using courier imap, I'm happy with it and I agree that a
mailserver should not try to fix broken MUAs. Nevertheless, Sams's approach
to interprete specs is somewhat irritating (though I sympathize with it
;-), you just have to know. I guess it's a late result of that sheet pinned
to the inside of his room's door with the one word printed upon.
Theo
DINH Viet Hoa
> mailserver should not try to fix broken MUAs.
In fact, here the problem is to write specific parts of a client to fix a
broken mailserver.
--
DINH V. Hoa,
libEtPan! - a mail library - http://libetpan.sourceforge.net
"Quand tu discutes avec un chasseur, ton QI est au moins divisé par 2"
Terje Trane
news:courier.3CFF...@ny.email-scan.com...
> > The specification is not as wrong as you are saying, just that
> > it is the choice of the author of the specification.
>
> If someone made a bad choice, I am not obligated to follow it.
>
No of course not, you just say that you are not IMAP-compliant, then it's
ok.
A similar example. The TV system in USA, NTSC is a bad choice (stupid
compromises, Never Twice the Same Color or whatever it stands for). But you
are totally free to make a receiver that uses better technology choices.
(but you want be able to see much, but that doesn't matter since at least
you are not implementing somones bad choices)
> Look: everyone in front of you is jumping off a cliff. It's your turn
now.
You are perfectly free to choose not to jump, but then you cannot call
yourself a common hamster.
Mark Crispin
> On Tue, 11 Jun 2002, Terje Trane wrote:
> > A similar example. The TV system in USA, NTSC is a bad choice (stupid
> > compromises, Never Twice the Same Color or whatever it stands for). But you
> > are totally free to make a receiver that uses better technology choices.
> > (but you want be able to see much, but that doesn't matter since at least
> > you are not implementing somones bad choices)
> In contrast, I think it's the best in the world.
The "never twice the same color" stuff came from the bad old days of
vacuum tube TV sets, where NTSC was indeed considerably less color-stable
than PAL or SECAM sets. Even changing a channel required a complete
readjustment to correct green (or purple) faces.
The advent of digital solid-state sets brought an end to that decades ago.
Most people never adjust the color settings on their TVs from the factory
defaults. A few dedicated videophiles get out the blue filters to adjust
for color bars.
I admit to using a blue filter, but only to adjust the levels on the
S-Video to RGB converter; my TV has RGB video input, but not S-Video.
The TV's factory settings for TV and composite video are fine as-is even
after 15 years.
Today, the argument for the superiority of PAL or SECAM has to do with the
greater number of scan lines in the dozen or so TV systems used worldwide
with PAL or SECAM color. However, those extra scan lines come at a cost:
50Hz instead of 60Hz update rate. I get a headache watching PAL in Europe
because I can see the 50Hz flicker. As for SECAM...the less said the
better; I can't see how anyone can claim that SECAM is any good.
> Do you know a better one?
Supposedly, the Brazilians (at least I think that it's Brazil) have the
ultimate in analog. They use the 60Hz TV system M used in the Americas
(including the US), South Korea, Japan, the Philippines, and a few other
countries, but with PAL color encoding. It's called PAL-M.
However, with modern TVs, I doubt that there is a noticable difference
between PAL-M and NTSC (which is only used with TV system M).
Terje Trane
news:Pine.WNT.4.44.0206150502580.-310707@baku...
> On Tue, 11 Jun 2002, Terje Trane wrote:
> Why do you think NTSC is a bad Color TV System?
>
> In contrast, I think it's the best in the world.
I was trying to make a point of the value of following standards, not
harassing the NTSC standard (the "Never Twice.." statement is probably
something I remember from one of my teachers when I learned about
electronics a couple of decades ago).
> Do you know a better one?
Digital TV.
Neil Hoggarth
> Mark Crispin <m...@CAC.Washington.EDU> writes:
>
> > Today, the argument for the superiority of PAL or SECAM has to do with the
> > greater number of scan lines in the dozen or so TV systems used worldwide
> > with PAL or SECAM color. However, those extra scan lines come at a cost:
> > 50Hz instead of 60Hz update rate. I get a headache watching PAL in Europe
> > because I can see the 50Hz flicker.
>
> are there ones with 120 Hz available in the US?
I don't think so - but 60Hz large area flicker is much less noticable
than 50Hz; a consumer electronics company catering to the US market is
much more likely to make their TVs models that encorporate scan-rate
upconverters 525-line progressive scan or 1050-line interlace, I would
have thought?
Regards,
--
Neil Hoggarth Departmental Computer Officer
<neil.h...@physiol.ox.ac.uk> Laboratory of Physiology
http://www.physiol.ox.ac.uk/~njh/ University of Oxford, UK
Ian Clark
> The "never twice the same color" stuff came from the bad old days of
> vacuum tube TV sets, where NTSC was indeed considerably less color-stable
> than PAL or SECAM sets. Even changing a channel required a complete
> readjustment to correct green (or purple) faces.
A great story I read about the development of NTSC:
This is from New Scientist, 2 Jul 1994.
'Tis just 40 years since North American TV stations started broadcasting
in colour, using the NTSC system. Officially NTSC was named after the
National Television System Committee which chose it. Unofficially NTSC
has often been called Never Thrice the Same Colour.
A journalist who used to cover the NTSC told us recently of a lighter
moment at the laboratories of the record company RCA in Princeton, New
Jersey, where the system was developed. Team leader George Brown laid on
a final transmission test. A colour camera was focused on a bowl of
colourful fruit in one lab, and the received signal was displayed in
another lab on a prototype colour tube. Just before the test Brown took
a banana from the bowl and painted it blue.
For the rest of the day the engineers at the receiving end struggled
desperately to find out how their new system was faithfully reproducing
the colour of red apples, orange oranges and green grapes, but
resolutely converting yellow into blue.
> Today, the argument for the superiority of PAL or SECAM has to do with the
> greater number of scan lines in the dozen or so TV systems used worldwide
> with PAL or SECAM color. However, those extra scan lines come at a cost:
> 50Hz instead of 60Hz update rate. I get a headache watching PAL in Europe
> because I can see the 50Hz flicker. As for SECAM...the less said the
> better; I can't see how anyone can claim that SECAM is any good.
As a Brit, I'm used to higher res, lower frame rate. When I visit the US
I find the TV pictures smudgy. Additionally, more PAL-type TVs have
component RGB in.
>>Do you know a better one?
>
> Supposedly, the Brazilians (at least I think that it's Brazil) have the
> ultimate in analog. They use the 60Hz TV system M used in the Americas
> (including the US), South Korea, Japan, the Philippines, and a few other
> countries, but with PAL color encoding. It's called PAL-M.
>
> However, with modern TVs, I doubt that there is a noticable difference
> between PAL-M and NTSC (which is only used with TV system M).
The PAL colour gamut <http://www.fourmilab.ch/documents/specrend/>
covers a slightly larger area than the NTSC one, technically allowing
more colours, but this doesn't really mean anything in practise.
Marguerite LEBRETON
We use Netscape 4.75 Messenger to read our mail, with an imap server
(The UW imap4rev1 server) .When we send a mail, a copy of this mail is
put in an outbox mailbox. If we don't access the outbox by selecting it
in Messenger, the modification time is not changed on outbox. However,
imapd writes in outbox, so I don't understand why the modification time
is not changed. Only the ctime is modified.
The problem is that we are testing a new backup system. Before that,
the backup system was saving outbox, when the file was modified, even if
the last modification time was not changed. I don't know which method
this software was using to save the files, but I am sure it is not the
ctime. The new backup sytem we are testing does not backup outbox,
because this software looks at the last modification time.
Is there a method to force imapd to modify the date on a file when it
writes a mail in it?
Thanks for your help.
--
--
|Maguy LEBRETON - (TMSI/IDM/RIC) <mailto:Maguy.L...@ifremer.fr>
|IFREMER Institut Francais de Recherche pour l'Exploitation de la Mer
|Centre de Brest BP70 29280 PLOUZANE FRANCE
|Tel: 02 98 22 46 04 Fax: 02 98 22 45 46