Pb imap client with qmail+ldap+courier
Axel Bouet
I have qmail+ldap on a server, I use courier-imap for imap
and pop3, but I have a problem with outlook express imap client.
Courier-imap is compiled with the option for Netscape bug,
it's ok in Netscape, but I have bugs in outlook.
When I read a new mail, it seems to go to read state, but
on the server, the file does not change it status. So,
with a "send/receive", the read mail goes back to unread state.
It's the same for deleted mail.
If I change folder and come back to inbox, then, when I
read or delete a mail, it's ok, and the file state change
on the server.
What can I do to solve this problem ?
Thanks for the help.
Frank Klauert
> on the server, the file does not change it status. So,
> with a "send/receive", the read mail goes back to unread state.
> It's the same for deleted mail.
> If I change folder and come back to inbox, then, when I
> read or delete a mail, it's ok, and the file state change
> on the server.
>
> What can I do to solve this problem ?
Or another client.
Seriously:
I've seen this with Cyrus, too (so everything I write only
applies to Cyrus!! But both problems could be related). But
never with UW-IMAP and DKIMAP.
Outlook Express opens two connections to the IMAP-server:
One is for getting notified of new mail, selecting mails as read,
deleting them, downloading a new mail when you click on it, changing
the current folder, getting new message flags whenever entering a new
folder, etc.
Another one is used whenever the synchronising is happening and
for downloading all new mail.
Having two parallel IMAP-sessions is something that every IMAP-server
should handle well (it could be two different users on two different
PCs in the same account), although it is commonly seen as a bad design
decision of Outlook Express by most (I personally like it because
O.E. does not block the GUI while synchronising (you can start marking
mails as read and browsing through folders while the second connection
is still downloading 2 MB over ISDN), while Mulberry will block everything
every time it accesses the network).
And when I write "second connection" that really means one connection for
every folder, but MS will surely never fix this or anything else...
I saw the same problem you described and also an even worse problem
with Cyrus at someone else's place: It can be reproduced AFAICR
the following way: Mark everything for only downloading headers, not
the mail content. Then go in INBOX and have that folder being displayed.
Within the next 30 minutes (O.E. has a bug not sending an idle
command after that time...) let someone send you a mail. Then click
on send/receive, but don't leave the folder!! You should now
see the new mail appear in the windows. Click on it. It will
display in "strike through", will be marked for delete (or only
looks like that) and if you click on it O.E. will not be able
to download it, but tell you that it would be no more available
on the server.
The only "solution" I know is to reset the folder cache (delete
all offline messages) and let it refetch the headers.
I have found this discussion about it in google:
http://www.irbs.net/internet/info-cyrus/0111/0401.html
http://www.irbs.net/internet/info-cyrus/0111/0425.html
_If_ I interpret it correctly ("Cyrus caches seen state in memory for
a time before flushing it to disk.") it should be a fault of Cyrus.
If one user or O.E.-connection marks something as seen, then
all other sessions should immediately see the same state, not something
several minutes ago.
And for my problem:
Maybe the second connection O.E. uses sees new messages which
the first session is not aware of. O.E. stores the information and message
ids it receives from the second connection and expects them to
be right, but the first connection does not know about the new messages
(because it does not update it immediately) and says "not available"
I would really like to know whether Courier has this behaviour too
(not updating caches immediately), whether my problem also occurs
with Courier or only with Cyrus, if the idea for the reason of the problem
is correct or if it is something completely different, whether newer versions
of Cyrus still show the problem (carefully avoiding the word "fixed". On
the URL above, I really enjoyed reading the funny "I'd blame Outlook
Express but unfortunately I have another working IMAP server for
comparision ;)" ), ...
Can you check whether you have both problems or only the first?
Which version of Courier and O.E. do you use?
Hopefully this will be a interessting and lengthy discussion.
Axel Bouet
> (not updating caches immediately), whether my problem also occurs
> with Courier or only with Cyrus, if the idea for the reason of the problem
> is correct or if it is something completely different, whether newer versions
> of Cyrus still show the problem (carefully avoiding the word "fixed". On
> the URL above, I really enjoyed reading the funny "I'd blame Outlook
> Express but unfortunately I have another working IMAP server for
> comparision ;)" ), ...
>
> Can you check whether you have both problems or only the first?
> Which version of Courier and O.E. do you use?
>
I tried to have the second problem you described.
I have to say that it's the same with Courier-imap,
After 30 minutes, when I receive a mail, it appear in the inbox folder,
and when I click on it, it turn to deleted with error what says
the mail is no longer on the server.
On the server, the flags in the name of the email file did not change.
For the version, I use OE6 and Courier-imap 1.4.5 (09 May 2002).
Courier-imap was compiled with --enable-workarounds-for-imapclient-bugs
option, that seems to correct netscape bug, but not OE bug.
Have no idea for good the resolution of those problem.
Bert Stalone
> What can I do to solve this problem ?
Simple thing (actually not :-( , but it is absolutely worth the effort of
migration!): Get rid of Courier, because this is one of the reasons why it
really sucks.
Hint: Search the web and you'll find enough information about incompatibilities
of courier, one page is part of the official courier homepage, seems this was by design.
Sam
Hash: SHA1
In article <adg316$10j1ro$1...@id-147880.news.dfncis.de>,
"Bert Stalone" <nos...@spam.com> writes:
.:\:/:.
+-------------------+ .:\:\:/:/:.
| PLEASE DO NOT | :.:\:\:/:/:.:
| FEED THE TROLLS | :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you, | ( (_) )
| Management | /`-vvv-'\
+-------------------+ / Bert \
| | @@@ / /|,,,,,|\ \
| | @@@ /_// /^\ \\_\
@x@@x@ | | |/ WW( ( ) )WW
\||||/ | | \| __\,,\ /,,/__
\||/ | | | jgs (______Y______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE8+5Xt3ejdWUS0ltARAu1JAJ0RqS1B/6cs45mtVh1epJjfyooMmgCdF3SG
hywaQs1RyMdLGnZBUX2kLsA=
=dGnV
-----END PGP SIGNATURE-----
Mark Crispin
the standard, all you have to do if fix your server so that it complies.
-- 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.020603...@shiva0.cac.washington.edu>,
Mark Crispin <m...@CAC.Washington.EDU> writes:
> If you don't like people criticizing your server for non-compliance with
> the standard, all you have to do if fix your server so that it complies.
My server is compliant. Furthermore, that could hardly be called a
"criticism". Labeling Bert's blather as "criticism" is an insult to
critics everywhere.
On behalf of all those critics out there (of whom I consider myself to be
one), I DEMAND THAT YOU APOLOGIZE for labeling such as a pitiful display of
diaper-wetting as "criticism". Are you out of your mind? Have you no
shame at all? How DARE YOU insult fine critics everywhere by lumping them
together with this Bert character. Ugh... Just thinking about this
possibility makes me wretch with disgust.
I have you know that Criticology is a fine, age-honed and time-honored
institution. We critics are very proud of our masterful skills in
practicing our craft. Labeling such a pathetic, whining, and content-free
temper tantrum as "criticism" insults those of us who've devoted our entire
lives to our chosen profession, or hobby.
- --
Sam
P.S. And thank you for not criticizing Courier-IMAP either.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE8+8bX3ejdWUS0ltARAlXgAKCP67rQIsvZSKuA4WfqVxi5twZsNACeNjJz
lQRQbFZ2Lnm4Cn04nLy5kJ0=
=cBM3
-----END PGP SIGNATURE-----
Mark Crispin
> My server is compliant.
Saying that Courier-IMAP is compliant does not make it compliant.
Saying that the interoperability problems caused by Courier-IMAP's
non-compliance are client bugs does not make these client bugs.
Sam
Hash: SHA1
In article <Pine.LNX.4.50.02060...@shiva1.cac.washington.edu>,
Mark Crispin <m...@CAC.Washington.EDU> writes:
> On Mon, 3 Jun 2002, Sam wrote:
>> My server is compliant.
>
> Saying that Courier-IMAP is compliant does not make it compliant.
Saying that it's not compliant doesn't make it non-compliant either.
> Saying that the interoperability problems caused by Courier-IMAP's
> non-compliance are client bugs does not make these client bugs.
The interoperability problems in questions are due to errors, omissions,
and ambiguity in RFC 2060. Go complain to the guy who wrote it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE8+9se3ejdWUS0ltARApZjAJ0YPX/Hr/4Y+vzyG3rVC3ybd6XP4ACeMryj
X6X04cf1/ylNXUZp9cYPIYU=
=PHUS
-----END PGP SIGNATURE-----
Mark Crispin
> > Saying that Courier-IMAP is compliant does not make it compliant.
> Saying that it's not compliant doesn't make it non-compliant either.
Unless the person saying it is a recognized authority on IMAP compliance.
I am such an authority.
> > Saying that the interoperability problems caused by Courier-IMAP's
> > non-compliance are client bugs does not make these client bugs.
> The interoperability problems in questions are due to errors, omissions,
> and ambiguity in RFC 2060. Go complain to the guy who wrote it.
Yes, there have been errors, omissions, and ambiguities in the IMAP
specification. However, intelligent people consult with the rest of the
IMAP community, seek correction, addition, and clarification; and then
update their implementation accordingly. You have not done this.
You seem to have an obsession with attacking me as having "wrote RFC
2060". Sorry to bust your bubble, but I did not write RFC 2060. I edited
RFC 2060. RFC 2060 was a collective effort of over 100 individuals.
Courier-IMAP is non-compliant with the IMAP specification. I am not the
only person who has told you, in detail, how Courier-IMAP fails to comply.
Courier-IMAP will remain non-compliant with the IMAP specification until
such time as you decide to fix it.
Sam
Hash: SHA1
In article <Pine.LNX.4.50.02060...@shiva1.cac.washington.edu>,
Mark Crispin <m...@CAC.Washington.EDU> writes:
> On Mon, 3 Jun 2002, Sam wrote:
>> > Saying that Courier-IMAP is compliant does not make it compliant.
>> Saying that it's not compliant doesn't make it non-compliant either.
>
> Unless the person saying it is a recognized authority on IMAP compliance.
> I am such an authority.
In your own mind.
>> > Saying that the interoperability problems caused by Courier-IMAP's
>> > non-compliance are client bugs does not make these client bugs.
>> The interoperability problems in questions are due to errors, omissions,
>> and ambiguity in RFC 2060. Go complain to the guy who wrote it.
>
> Yes, there have been errors, omissions, and ambiguities in the IMAP
> specification.
True, and how sad that some people insist on sticking to the letter of a
broken specification.
> However, intelligent people consult with the rest of the
> IMAP community, seek correction, addition, and clarification;
Also, intelligent people recognize and take into consideration the personal
biases and prejudices of all concerned parties.
> and then
> update their implementation accordingly. You have not done this.
And how do you know that? Don't tell me -- your crystal ball told you
that.
> You seem to have an obsession with attacking me as having "wrote RFC
> 2060". Sorry to bust your bubble, but I did not write RFC 2060.
...
The IMAP protocol engine used by PC Pine was written by the fellow who
invented IMAP and wrote the IMAP specification.
...
...
Disclaimer: I wrote the UW server and Pine's IMAP client code.
...
And before you start mouthing off about obsession this, and obsession that:
when someone sets off my BS detector by telling me something contrary to
what I believed to be true, I always try - as any reasonable person would
try - to double check my information. And, I must admit, the BS detector
was ringing its bells off, just now. It only took me literally five minutes
to pull this out of Google.
So, so, so ... what do we have here (a multiple choice exam, kids):
A) Megalomania, or
B) Trying to distance oneself from the flaming wreckage of a specification
that RFC 2060 turned out to be.
> I edited
> RFC 2060. RFC 2060 was a collective effort of over 100 individuals.
Ok, that's your new story now. Well, my previous suggestion stands, then:
as I said, complain to them.
> Courier-IMAP is non-compliant with the IMAP specification.
It is compliant with the bug-free version of the specifications. If one
such exists, of course. If one doesn't, then I just do my best to fill in
the blanks and work with the closest approximation I can figure out.
> I am not the
> only person who has told you, in detail, how Courier-IMAP fails to comply.
Neither you, nor anyone else, "told" me anything of that sorts. All I've
heard is a bunch of pissing and moaning, because I declined to kow-tow the
party line regarding how IMAP software is "supposed" to work. You view IMAP
as your private little fiefdom, with yourself as an absolute ruler, and
anyone wishing to live in that fiefdom must obtain the royal blessing for
doing so. And IMAP software is supposed to work according to how the
emperor thinks it should work; anyone who dares to challenge the eternal
wisdom of the Supreme Ruler is a heathen that must be banished to Hades.
And this barbarian not only had the gall to point out the multitude of
errors and flaws in the specification -- more commonly known as the
"emperor had no clothes" syndrome -- but also had the gall to do the
impossible and implement an IMAP server in a way that the Supreme Ruler had
claimed for years will never work, or would be horribly inefficient and
unusable.
> Courier-IMAP will remain non-compliant with the IMAP specification until
> such time as you decide to fix it.
Nothing needs to be fixed. At least at the time I'm writing this. Your
lame FUD-generating tactics are rather sad, actually.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE8/AsS3ejdWUS0ltARAiEkAJ9N6P5YDOIWqiNCooTJjRpQ1PWpeQCdF2vV
FUTo15ys5symWeC84X5Wa6k=
=3kAJ
-----END PGP SIGNATURE-----
Richard
Ok...so let me get this straight.
Sam is the author of...wait..checking /usr/src/courier-imap-1.3.10/AUTHORS
... Well, I'll be! Greetings SAM!
and Mark is at least someone who has worked on the IMAP RFC (2060) and is
{maybe} an author of PINE.
Courier-IMAP is just a SERVER, and Pine is just a client (oh and maybe a
pop3 server).
If all of those assumptions are correct my .02 would be this... In a world
where a particular company tries to dominate the market and change internet
and computing standards presumably in an effort to retain market share ---
In such a world, can we really continue such a heated debate on following
exact standards? I think the name of the game here is compatibility and
interoperability. I have used the PINE email client and the pico editor.
They are both included on every Slackware version I've installed. I've also
used POP3 servers in the past. I can't tell you how much of a headache that
was. Courier IMAP has been a godsend!
Now I don't know who's right and who's wrong, and for the most part I don't
care. I will say that I have had a difficult time getting PINE to work with
my MAILDIR configuration of Qmail. I eventually gave up. Of course it's
been a few revs back since I've tried. I would be the only person using it
on the system anyway. I don't expect PINE to be supported on every
conceivable email server implementation, but Qmail Maildirs are a BIG STABLE
thing!
I for one have widely deployed the Courier IMAP server for use by several
IMAP clients. In the case that started this thread, if OE is unable to
display a message I just instruct the user to click on another IMAP folder
and click back. Walla--resync! The server seems to work properly for me!
If a mail server is compliant with my user's mail clients, then by god it's
compliant!
Maybe the RFC needs updating...I don't know, blame that other company but
for goodness sake enough is enough. At least take it outside the newsgroup.
Oh and Sam, I appreciate the security precautions you make users take during
compile time. Qmail and Courier security is such a contrast to the constant
issues in Sendmail and WUFTP.
[/soapbox]
(It's late...I'm delierous. Take everything I say with a grain of
salt...because that's about all it's truly worth.)
-Richard
Sam
Hash: SHA1
In article <bQXK8.55328$0A2.44857@rwcrnsc54>,
"Richard" <nospam...@no.sp.am.geocities.com> writes:
> I for one have widely deployed the Courier IMAP server for use by several
> IMAP clients. In the case that started this thread, if OE is unable to
> display a message I just instruct the user to click on another IMAP folder
> and click back. Walla--resync! The server seems to work properly for me!
This is actually a known bug in OE. I've logged OE opening two server
logins and selecting the same folder both times. After the first login
picks up new UIDs after getting an unsolicited EXISTS, it then sends a
FETCH to a second session, which hasn't seen the new mail yet. The failed
FETCH then makes OE think the message has disappeared. Hence the
appearing/disappearing trick. Going to another folder, then coming back
reselects the folder in both logins, which are now in the same state, with
a consistent folder view. This behavior has been observed only in some
versions of OE, and is only triggered under some undetermined combinations
of OE version builds, MSIE version builds, and NT service packs.
There's actually a second bug in some versions of OE that results in
similar UI behavior, and I posted those logs here some months ago, for
kicks: OE becoming terribly confused, and sending a CLOSE after an EXISTS,
and before the FETCH. It's not clear what it's trying to FETCH, after
closing the folder. The client/server synchronization is now complete out
of kilter. What I didn't post is what follows, when the client tries to
recover by resending the same FETCH, which doesn't accomplish much either.
Eventually a watchdog counter in the server is tripped, that mercifully
closes the connection after getting too many consecutive protocol errors,
breaking the infinite loop. OE then complains about the server closing the
connection, the luser complains to comp.mail.imap, or imap-list, then
Crispin, and his groupies, use that as an excuse to have a cow.
And that's what this is really all about. Some people just prefer
to have a cow now and then, I guess.
> Oh and Sam, I appreciate the security precautions you make users take during
> compile time. Qmail and Courier security is such a contrast to the constant
> issues in Sendmail and WUFTP.
Aww shucks, that's shweet. But don't thank me, thank Mark. If it weren't
for the lack of solid maildir support in pine/c-client (which you have
concisely observed yourself) some years ago, I would not've started the
project. So, in a way, he inspired me; and the kudos rightfully belong to
him. How does that grab you? It's absolutely true; if pine/c-client had
good maildir support back in, oh '96-'97, I don't know if I would've
started the project, or not (this one should be good enough to keep the cow
going). I might've went ahead anyway, for some reason, but we'll never
know. I tell you what though: I would've definitely gone ahead, no matter
what, had I known how much fuuuuun I'd have years later down the road.
If you have the impression that this is a heated flamefest, go back and
re-read the thread. Again, and again, until you change your mind. It's
not, not as far as I'm concerned. I think it's priceless comedy. First,
some poor soul was confused about some issue, and asked a question.
Although I could've made some pretty good guesses, experience told me that
the poster might've bit off a little bit more than he could chew (to put it
gently) and the same experience advised me just to let that one go by.
Besides, people tell me I'm too rough on newbies, so I'm trying to kick
the habit.
That would've been it, but some refugee from imap-list felt the need to
weigh in with his words of wisdom. Well, newbies are one thing, but
full-fledged looney-tunes deserve no mercy. You can't really talk to these
kinds of loons, don't even bother. The best response is just to have a
laugh at them, and I always have a small collection of nice ASCII art ready
for just such an occasion.
And that would've been the end of it AGAIN, but then Crispin had to make
his grandiose appearance. Right on cue, and, as always, completely off the
mark, and singing a wrong melody.
And the show was on. I wouldn't expect everyone to appreciate my sense of
humor; if you didn't - to each his own. But one really has to be
incredibly dense to think that I took his groupie's mini-rants seriously.
Well, you, you have an excuse, looks to me you're a new face around here
(at least as far as comp.mail.imap is concerned). You can have some slack
cut for that. But the Grand Poobah himself isn't, so what's his excuse?
Go read his initial words of wisdom, he actually thought Bertie bothered
me. Reread the whole thread and even if you don't particularly care for my
heavy layer of irony, if you still believe that I really took both
looney-tunes seriously (and I never do) I'll eat my official Red Hat
T-shirt.
Of course, I suppose, there's still some infinitessimally small possibility
that Crispin's is the real supertroll (and he deserves his own ASCII art
for that), pretending to believe that I believe that I took Bertie
seriously, while really understanding fully well that I didn't really give
a fig about any of these yahoos. Well, if that's the case, I'm at a loss
for words, and I must tip my hat in respect for such a masterful
mega-troll.
Who needs cable-TV, when there's comp.mail.imap?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE8/Gpf3ejdWUS0ltARAiakAJ4vO7B2MozCk36RyjSmcJXKJeD0KACfRj67
VL8h8NhpDvdkLquxbGSFMC8=
=RQ75
-----END PGP SIGNATURE-----
Frank Klauert
About whether that's a bug or a feature or a bad design decision of MS
there are different oppinions.
But consider a large fraction of any IMAP-servers userbase to be Outlook-
Express-users, maybe Outlook-Express-loosers.
> logins and selecting the same folder both times. After the first login
> picks up new UIDs after getting an unsolicited EXISTS, it then sends a
> FETCH to a second session, which hasn't seen the new mail yet. The failed
> FETCH then makes OE think the message has disappeared. Hence the
> appearing/disappearing trick. Going to another folder, then coming back
> reselects the folder in both logins, which are now in the same state, with
> a consistent folder view. This behavior has been observed only in some
Clicking on another folder and back didn't help for me when I used
Cyrus (not courier-imap! But the problems _of_ OE _with_ both seems to be
the same), I had to delete O.E.'s cache!
They were using Win XP with Outlook Express 6.
Loosing mail is the worst that can happen and having users thinking
that is also not good.
Why doesn't Courier tell other (all) open sessions about new mailarrival?
Would that be too hard to implement, would it mean too much
performance-loss with maildir, don't you care or do you have good
reason to do so?
Is RFC2600 unclear about this thing?
Or is it a weakness of Cyrus and Courier, which can best be solved by
admins of those servers bashing MS and Outlook Express? ;-)
If I let O.E. cause anything to happen with IMAP (e.g. fetching a mail
while I'm in a folder), e.g. DKIMAP will immediately notify it of any
new mail, even if this mail was stored on the server by another session
on another computer in the mean time.
That (IMAP's notification features) is a grat feature if servers and clients
support it fully, imagine several e.g. PINE-users in tech-support working together
on the same folder, always staying in that folder (not regularly going to another
folder and back to have a new select-call happen).
If one answeres a message and changes its flags or if a new one arrives, the others
will immediately know about it.
Are there any planned changes in Courier about this issue?
Does anybody know if Cyrus' behaviour with this issue has changed in newer
versions?
Are there other servers that show this problem with O.E.?
Sam
Hash: SHA1
In article <adhv5s$11brjm$1...@id-140432.news.dfncis.de>,
"Frank Klauert" <frank....@hotmail.de> writes:
>> This is actually a known bug in OE. I've logged OE opening two server
>
> About whether that's a bug or a feature or a bad design decision of MS
> there are different oppinions.
>
> But consider a large fraction of any IMAP-servers userbase to be Outlook-
> Express-users, maybe Outlook-Express-loosers.
Consider what, exactly?
Let's just pretend to live in a fantasy world, where every bug in OE is
tagged, tracked, researched and labeled, and all the necessary hacks to
avoid them are identified, and implemented.
What do you think is going to happen next?
What's going to happen next is a new set of bugs will mysteriously appear,
even more bizarre in nature. Why's that? Well, it shouldn't be too
difficult to figure it out. But, I'll leave that as a homework assignment,
for next time. The bottom line that chasing after MS's bugs is a complete,
and total, waste of time.
> Why doesn't Courier tell other (all) open sessions about new mailarrival?
> Would that be too hard to implement, would it mean too much
> performance-loss with maildir, don't you care or do you have good
> reason to do so?
The cost/benefit ratio is simply not worth it. In fact, unsolicited server
messages are something that tends to kick off the most bizarre kind of
client bugs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE8/M+q3ejdWUS0ltARAnm7AJ4nfe3ztfq/FiUR6wqsHVTIvEyAgwCgkCGh
gJ7wrAcY6W/PInaneys6utw=
=WvGd
-----END PGP SIGNATURE-----
Ken Murchison
Sam wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In article <Pine.LNX.4.50.02060...@shiva1.cac.washington.edu>,
> Mark Crispin <m...@CAC.Washington.EDU> writes:
>
> > On Mon, 3 Jun 2002, Sam wrote:
> >> My server is compliant.
> >
> > Saying that Courier-IMAP is compliant does not make it compliant.
>
> Saying that it's not compliant doesn't make it non-compliant either.
>
> > Saying that the interoperability problems caused by Courier-IMAP's
> > non-compliance are client bugs does not make these client bugs.
>
> The interoperability problems in questions are due to errors, omissions,
> and ambiguity in RFC 2060. Go complain to the guy who wrote it.
Have you bothered to read any of the updated drafts to make sure that
all of the "errors, omissions,
and ambiguity" have been corrected? If so, then you should know that
they are being resolved, and code your server accordingly. If not, why
not? If you don't take the time to make sure that they are fixed to
your liking, then AFAIC, you give up your right to bitch.
Let's all be part of the solution, not part of the problem.
Ken
--
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
Sam
Hash: SHA1
In article <3CFCF12F...@oceana.com>,
Ken Murchison <k...@oceana.com> writes:
> Have you bothered to read any of the updated drafts to make sure that
> all of the "errors, omissions,
> and ambiguity" have been corrected? If so, then you should know that
> they are being resolved, and code your server accordingly. If not, why
I prefer to wait until everything stabilizes. I think I'll pass on chasing
a moving target. Someone else can do that, instead of me.
> not? If you don't take the time to make sure that they are fixed to
> your liking, then AFAIC, you give up your right to bitch.
It's painfully clear to me that any time and effort from me trying to "play
with the ball" is going to be a complete waste of time. Not when better
solutions are possible. Case in point, for example: NNTP and yEncoding.
Furthermore, who's bitching? I'm quite happy with sitting quietly on the
side, offering some helpful suggestion to an occasional question, once in a
while. But when someone starts barking mad, without a clue, I see nothing
wrong with having a few yucks at their expense. Just to break up the
boredom, that's all. I don't pick fights first, or start complaining on my
own.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE8/Q0u3ejdWUS0ltARAqw6AJ4u2kGObJjJGVCX8jwBTsJnk6khtQCfQp4i
/j8aN90d+uzGTpCVlQZBZU4=
=XlBw
-----END PGP SIGNATURE-----
Mark Crispin
> I don't pick fights first, or start complaining on my
> own.
You have done nothing but pick fights and complain.
Courier-IMAP would have been compliant long ago if you spent half the
energy in fixing the protocol compliance bugs in Courier-IMAP that you
have in your attacks on me, the IMAP specification, the IESG, and
everybody else's IMAP implementation.
Sam
Hash: SHA1
In article <Pine.LNX.4.50.02060...@shiva1.cac.washington.edu>,
Mark Crispin <m...@CAC.Washington.EDU> writes:
> On Tue, 4 Jun 2002, Sam wrote:
>> I don't pick fights first, or start complaining on my
>> own.
>
> You have done nothing but pick fights and complain.
Really? Please post an example of me picking a fight. Who started yapping
in this thread first, hmmmm? Here's the thread:
References: <3CF1FC40...@atac.fr> - original question
<adg316$10j1ro$1...@ID-147880.news.dfncis.de> - the troll
<courier.3CFB...@ny.email-scan.com> - me laughing at the troll
<Pine.LNX.4.50.020603...@shiva0.cac.washington.edu>
- you mouthing off, and complaining
Perhaps you have another thread in mind, which better supports your claim.
This one doesn't.
> Courier-IMAP would have been compliant long ago if you spent half the
Courier-IMAP has been compliant for a long time. According to rules of
logic, a gratuitous assertion is gratuitously refuted.
> energy in fixing the protocol compliance bugs in Courier-IMAP that you
The bugs are in the protocol specification itself. Almost a hundred of
them. Anything that follows the exact letter of RFC 2060 is not going to
work at all with any mainstream IMAP software. I know that, you know that.
You don't like it. Well, deal with it. It's not my fault. This is a red
herring, and I don't eat fish.
> have in your attacks on me, the IMAP specification, the IESG, and
> everybody else's IMAP implementation.
I must've been out of town when the papal declaration promoting all of them
to the sainthood status, beyond the reach of any criticism, was handed out.
Can I have a copy?
If someone doesn't mind being mindless sheep, blindly obedient to anyone
he's told he should be blindly obey, that's their choice in life. But it's
not mine. I choose to excersize my own privilege, not to blindly follow
the herd. If I think that something, or someone, is stupid, then I'll
describe it as stupid, no matter who he, or it, is.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE8/StW3ejdWUS0ltARArDlAJ4+xHXUPkJLhN7fBD1Lv8f7C1QqQgCdFJ59
sni7Q0YaBqxF38/KqE0W6J4=
=Oo+d
-----END PGP SIGNATURE-----
Frank Klauert
Sorry for repeating the same questions again and again, but I really
want to know about this!
> Courier-IMAP would have been compliant long ago if you spent half the
Can you tell whether the expirienced problem is because of Courier
violating the IMAP-protocol?
I have read that you don't like Outlook Express to open more than one
connection to the imap-server, and I can understand why a good client
should only open one connection.
But if either
a) one user uses his Outlook Express with two parallel connections
or
b) two or more people working together on one shared folder open this
folder in parallel
then this problem seems to come up.
Did you face the problems that started the thread when you tested
O.E. against your IMAP-server?
Can you comment on the suggested reasons why this is happening? Are
they right or wrong?
Should Courier and Cyrus urgently have another behaviour with concurrent
sessions and notification about updates or is it okay what they do
(according to the RFC AND what is best and sane behaviour for an
imap-server)?
Is Outlook Express only misbehaving in the contex of this issue or is
that problem a _real_ bug? (Unfortunately lots of people get it
preinstalled and like it and MS seems to have no plans to fix or improve
anything with OE but security holes.)
Thanks to everyone for any usefull information on that topic!
Frank Klauert
> them. Anything that follows the exact letter of RFC 2060 is not going to
> work at all with any mainstream IMAP software. I know that, you know that.
> You don't like it. Well, deal with it. It's not my fault. This is a red
> herring, and I don't eat fish.
>
--------------------------
| |
/| /| | Please stop |
____||__|| __ feeding |
_/ O O\__ \ the troll |
/ \ \ |
| \ \ |----------------------
/ \ \ \ ||
| ____\ \ | ||
/ /|_|_|\____/ \ __||
| /__ ~~@~ ___ |_ __| ||
\ / \ \_|__~~~ ~@~\ / --|
| | | /| \_~~ ~\ ___ --|
\ | |// \ ~ ~\ \-/
* _ | |_|_|_| \ ~~@ \
*-- _--\ _ \ // / \~~~~\
/ _ \\ _ // | / \~@ ~~\ __ _
* / \_ /- | - | | |~~~@@@~~ \__
* ___ c_c_c_C/ \C_c_c_c__-_/~~~~~~~~~~@~~~~~\____
|~~~@@~~~~---~~~~m:cvn|
(Sorry, but I just *couldn't* resist!) ;-)
And for your reply to Bert's posting:
Si tacuisse, philosophus mansisse
Richard
"Sam" <s...@email-scan.com> wrote in message
news:courier.3CFC...@ny.email-scan.com...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In article <bQXK8.55328$0A2.44857@rwcrnsc54>,
> "Richard" <nospam...@no.sp.am.geocities.com> writes:
>
> > I for one have widely deployed the Courier IMAP server for use by
several
> > IMAP clients. In the case that started this thread, if OE is unable to
> > display a message I just instruct the user to click on another IMAP
folder
> > and click back. Walla--resync! The server seems to work properly for
me!
>
> This is actually a known bug in OE. I've logged OE opening two server
> logins and selecting the same folder both times. After the first login
> picks up new UIDs after getting an unsolicited EXISTS, it then sends a
> FETCH to a second session, which hasn't seen the new mail yet. The failed
> FETCH then makes OE think the message has disappeared. Hence the
> appearing/disappearing trick. Going to another folder, then coming back
> reselects the folder in both logins, which are now in the same state, with
> a consistent folder view. This behavior has been observed only in some
> versions of OE, and is only triggered under some undetermined combinations
> of OE version builds, MSIE version builds, and NT service packs.
>
Ok...Nice explaination. I suppose a bug free software program was too much
to ask from 'that company'
> There's actually a second bug in some versions of OE that results in
> similar UI behavior, and I posted those logs here some months ago, for
> kicks: OE becoming terribly confused, and sending a CLOSE after an EXISTS,
> and before the FETCH. It's not clear what it's trying to FETCH, after
> closing the folder. The client/server synchronization is now complete out
> of kilter. What I didn't post is what follows, when the client tries to
> recover by resending the same FETCH, which doesn't accomplish much either.
> Eventually a watchdog counter in the server is tripped, that mercifully
> closes the connection after getting too many consecutive protocol errors,
> breaking the infinite loop. OE then complains about the server closing
the
> connection, the luser complains to comp.mail.imap, or imap-list, then
> Crispin, and his groupies, use that as an excuse to have a cow.
>
> And that's what this is really all about. Some people just prefer
> to have a cow now and then, I guess.
>
[snip the sweetness and pine's lack of Maildir support]
> If you have the impression that this is a heated flamefest, go back and
> re-read the thread. Again, and again, until you change your mind. It's
> not, not as far as I'm concerned. I think it's priceless comedy. First,
> some poor soul was confused about some issue, and asked a question.
> Although I could've made some pretty good guesses, experience told me that
> the poster might've bit off a little bit more than he could chew (to put
it
> gently) and the same experience advised me just to let that one go by.
> Besides, people tell me I'm too rough on newbies, so I'm trying to kick
> the habit.
>
[snip Crispin's cow]
> And the show was on. I wouldn't expect everyone to appreciate my sense of
> humor; if you didn't - to each his own. But one really has to be
> incredibly dense to think that I took his groupie's mini-rants seriously.
> Well, you, you have an excuse, looks to me you're a new face around here
> (at least as far as comp.mail.imap is concerned). You can have some slack
> cut for that.
Well, I've been lurking for a while, but I'm implementing these things in
the field and I no longer have infinite time to solve issues. I'll also try
to give back where I can but it will NEVER match Dave.
[snip Crispin the mega troll providing more entertainment than Cable TV]
Actually I did find the whole thread absolutely and unequivocally hilarious.
I had to share some of it with my wife who listened to me stolidly. I guess
one would have had to have been there. I will admit to toning down my
message as I didn't want to seem to be attacking a certain...troll. After
all have you seen his web page! In the woods and EVERYTHING! Coincidence
or astonishing fact? You be the judge.
But I digress. From what I know not, nevertheless drivel spewith forth.
So then Sam I am, which green eggs from 'that company' work best with the
"courier" (and for the non English, non Dr. Suess literate that question
translates to: Which Win32 based IMAP clients do you recommend be used with
your Courier IMAP server? )
-Richard, the way too tired and mostly delirious
Sam
Hash: SHA1
In article <OFfL8.198403$Po6.3...@rwcrnsc52.ops.asp.att.net>,
"Richard" <nospam...@no.sp.am.geocities.com> writes:
> So then Sam I am, which green eggs from 'that company' work best with the
Well 'that company' makes only one IMAP client, OE, and we all know how
that turned out to be.
> "courier" (and for the non English, non Dr. Suess literate that question
> translates to: Which Win32 based IMAP clients do you recommend be used with
> your Courier IMAP server? )
Oh... Well, in that case, I'd have to say Mozilla's IMAP client appears to
be fairly sane. There's a trifle issue with Mozilla opening up to five
concurrent logins, for some silly reasons, and my default settings allow a
maximum of four logins from the same IP address. But this setting is a
no-brainer to reset, and the nice chaps on the other side even fixed their
code so that it recovers from a login failure gracefully.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE8/YzK3ejdWUS0ltARAoCjAJ0WnlFCgYumRVrYqlP0rlZP6zXjDACfQFFJ
cVGwGkvz1jrjDGyrPm9ElLo=
=juVC
-----END PGP SIGNATURE-----
Russell Nelson
I've found it best to keep djb and mrc as far away from each other as
possible, even avoiding the words qmail and imap in the same sentence.
And that would be the Newsgroups: line above, eh?
So, can we please cut it out?
--
-russ nelson http://russnelson.com | I don't want to give up
Crynwr sells support for free software | PGPok | essential liberty to obtain
521 Pleasant Valley Rd. | +1 315 268 1925 voice | a little temporary safety.
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | Is anyone listening to me?