Q: Fast searching Imap server
Jan Kybic
I put all my mail (now about 30MB) into a local IMAP server,
currently Courier-IMAP. I frequently search for old mails with
commands such as 'SEARCH SINCE 1-Oct-2001 FROM jan TO jurgen' but they
seem to take eternity, I think the server just goes through all the
messages one by one.
Would you know about an IMAP server which stores important information
about messages (data, from, to, subject) in some sort of a database so
that the searches are quicker?
Thank you,
Jan
--
-------------------------------------------------------------------------
Jan Kybic <ky...@ieee.org> Robotvis, INRIA, Sophia-Antipolis, France
or <Jan....@sophia.inria.fr>,tel. work +33 492 38 7589, fax 7845
http://www-sop.inria.fr/robotvis/personnel/Jan.Kybic/
Mark Crispin
> I put all my mail (now about 30MB) into a local IMAP server,
> currently Courier-IMAP. I frequently search for old mails with
> commands such as 'SEARCH SINCE 1-Oct-2001 FROM jan TO jurgen' but they
> seem to take eternity, I think the server just goes through all the
> messages one by one.
That's the price you pay for the maildir format used by Courier.
> Would you know about an IMAP server which stores important information
> about messages (data, from, to, subject) in some sort of a database so
> that the searches are quicker?
Cyrus.
Or use UW, which uses flat files that are much faster to search.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Sam
Hash: SHA1
In article <Pine.NXT.4.41.011106...@tomobiki-cho.cac.washington.edu>,
Mark Crispin <m...@CAC.Washington.EDU> writes:
> On 6 Nov 2001, Jan Kybic wrote:
>> I put all my mail (now about 30MB) into a local IMAP server,
>> currently Courier-IMAP. I frequently search for old mails with
>> commands such as 'SEARCH SINCE 1-Oct-2001 FROM jan TO jurgen' but they
>> seem to take eternity, I think the server just goes through all the
>> messages one by one.
>
> That's the price you pay for the maildir format used by Courier.
>
>> Would you know about an IMAP server which stores important information
>> about messages (data, from, to, subject) in some sort of a database so
>> that the searches are quicker?
>
> Cyrus.
>
> Or use UW, which uses flat files that are much faster to search.
Courier beats UW when searching large mailboxes, on mid-sized hardware:
http://www.courier-mta.org/mbox-vs-maildir/#testset2
10,000 messages, in a 40MB folder:
UW-IMAP: 8.7-8.9 seconds for a full mailbox search.
Courier: 7.5 seconds for a full mailbox search.
Absolute and unqualified performance claims is easily debunkable FUD, and
nothing else. If someone were to actually do some basic research, they
would reach a conclusion that actual performance, in real life, depends on
many factors: such as actual disk drive hardware, RAM, CPU, network
infrastructure; and many other factors. One person will see better
results from UW-IMAP, given his hardware, software, and mail traffic
patterns; someone else will see better results from Courier in their case.
Absolute claims of superior performance, under every imaginable hardware,
software, and network configuration, are intellectually bankrupt.
As far as caching mail headers go, again, a real life investigation would
uncover some interesting surprises: such as the fact that the majority of
IMAP mail clients already cache headers. Name them: Outlook/Outlook
Express, Netscape/Mozilla. All of them cache headers. And that takes care
of how much of the total IMAP mail client population? 80%? 85%? 90%?
Caching your mail headers will certainly do you a lot of good, when the
mail client will never ask for them again. Jan Kybic's needs are rather
unique, and are not representative of the needs of an average IMAP user.
Not everyone needs to be able to frequently search a large pile of mail,
and would benefit from agressive server caching.
You are just making a mistake thinking that every IMAP mail client in the
world works just like Pine. You are very, very mistaken.
The only potential savings (as opposed to technically sophisticated
algorithms that were written only to provide material for a dissertation
paper, but serve no useful real-world purpose otherwise) from caching mail
headers can come about if the server has sufficient intelligence to notice
which mail headers the IMAP client usually asks for, and automatically
cache those headers, in advance, on all newly arrived mail, anticipating
that the mail client will request them in the future.
To the best of my knowledge, no such artificial intelligence exists in the
UW-IMAP server. I don't know about Cyrus. I doubt it, but it's possible
that it does something like that. Even if it does it, all that it actually
translates to, in real life, is a slightly faster response to client
requests, provided that the IMAP client usage is a typical representative
of the total IMAP client population - the majority of which cache mail
headers. The server will still rarely get more than one request for the
same set of mail headers, the only difference would be that the server read
those headers before, or after, the request. The final bottom line will be
a slightly faster client response, no change on the server side (just the
header reading load will be shifted in time), and additional storage and
complexity that results from having to maintain a separate mail header
database.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE76G2v3ejdWUS0ltARAme+AJ4wu3gF62EidlgrZnx5tKPzw3qlngCdHOsF
58QKwWUfcxgT1dR2sgwbW2w=
=4Jpw
-----END PGP SIGNATURE-----
Mark Crispin
> Courier beats UW when searching large mailboxes, on mid-sized hardware:
> UW-IMAP: 8.7-8.9 seconds for a full mailbox search.
> Courier: 7.5 seconds for a full mailbox search.
1) What is a "full mailbox search"? That is not an IMAP term.
2) Does Courier search in non-ASCII charsets? The last statement made on
this newsgroup on that topic was the Courier did not and would not do so.
3) Does Courier decode content-transfer encodings and encoded words prior
to searching, as required by the specification?
4) Does Courier know not to search non-textual MIME segments in TEXT
searches? Does Courier know not to search MIME headers and non-textual
MIME segments in BODY searches?
5) When does Courier obtain the metadata necessary to do (3) and (4)?
Unlike Cyrus, neither Courier's maildir format nor the format supported by
UW store the necessary message metadata. Thus, the server has to look at
the message data to obtain the metadata; that is, it has to parse RFC822
and MIME headers.
If UW doesn't have metadata, 63% of its search time is taken in obtaining
metadata; put another way, a second identical text search takes 37% of the
time the second time around because the metadata is now there. Once the
metadata is loaded, non-text searches (including header searches) are
instantaneous in UW since it's in the metadata.
6) If Courier obtains metadata, what are the comparable SEARCH times for a
second SEARCH in the two servers, so that metadata costs don't distort the
figures?
7) If Courier does not obtain metadata, decode encodings, and search only
the proper textual segments of messages, then what validity does the
comparison have? A proper comparision would be against fgrep. How does
Courier fare in subsequent searches?
By the way, does Courier implement the specification's formal syntax at
long last? Or does Courier still take the position that it refuses to
comply with selected areas of the specification since that would render
its code into "spaghetti"?
> the majority of
> IMAP mail clients already cache headers. Name them: Outlook/Outlook
> Express, Netscape/Mozilla.
So POP3 clients hacked to babble IMAP represent the "majority" of clients,
and are the only ones for which a server should optimize??
> Jan Kybic's needs are rather
> unique, and are not representative of the needs of an average IMAP user.
So the needs of a user who uses IMAP the way it is intended is "unique"
and "not representative"?
> You are just making a mistake thinking that every IMAP mail client in
> the world works just like Pine.
Every good IMAP client in the world works in a manner similar to Pine.
The future belongs to those clients. The fact that some vendors
distributed crappy clients doesn't mean that servers should optimize for
them.
Sam
Hash: SHA1
In article <Pine.NXT.4.41.011106...@tomobiki-cho.cac.washington.edu>,
Mark Crispin <m...@CAC.Washington.EDU> writes:
> On Tue, 6 Nov 2001, Sam wrote:
>> Courier beats UW when searching large mailboxes, on mid-sized hardware:
>> 10,000 messages, in a 40MB folder:
>> UW-IMAP: 8.7-8.9 seconds for a full mailbox search.
>> Courier: 7.5 seconds for a full mailbox search.
>
> 1) What is a "full mailbox search"? That is not an IMAP term.
A search that hits every message in the folder.
> 2) Does Courier search in non-ASCII charsets? The last statement made on
Yes.
> this newsgroup on that topic was the Courier did not and would not do so.
>
> 3) Does Courier decode content-transfer encodings and encoded words prior
> to searching, as required by the specification?
Uh-huh..
> 4) Does Courier know not to search non-textual MIME segments in TEXT
> searches? Does Courier know not to search MIME headers and non-textual
> MIME segments in BODY searches?
Yes.
> 5) When does Courier obtain the metadata necessary to do (3) and (4)?
The MIME headers.
Doh.
> Unlike Cyrus, neither Courier's maildir format nor the format supported by
> UW store the necessary message metadata. Thus, the server has to look at
> the message data to obtain the metadata; that is, it has to parse RFC822
> and MIME headers.
Correct. And even then Courier still beats UW on some hardware
specifications.
> If UW doesn't have metadata, 63% of its search time is taken in obtaining
> metadata; put another way, a second identical text search takes 37% of the
> time the second time around because the metadata is now there. Once the
> metadata is loaded, non-text searches (including header searches) are
> instantaneous in UW since it's in the metadata.
If you cared to look at the numbers, you'd see that two full folder
searches were done, one after another.
> 6) If Courier obtains metadata, what are the comparable SEARCH times for a
> second SEARCH in the two servers, so that metadata costs don't distort the
> figures?
You are welcome to read the results for yourself. There are three separate
sets of raw data, broken down by real, user, and system CPU time, measuring
multiple SELECT, DELETE/EXPUNGE, FETCH, and SEARCH runs, across different
hardware platforms and mailbox profiles. Plus memory usage metrics, and
graphs. Instead of reposting one or two individual benchmarks, one can get
a far more accurate pictures by looking at the entire benchmark.
> 7) If Courier does not obtain metadata, decode encodings, and search only
> the proper textual segments of messages, then what validity does the
> comparison have? A proper comparision would be against fgrep. How does
> Courier fare in subsequent searches?
N/A.
You know, you're not the only person in the world who knows how to parse
MIME messages.
Actually I do have one small correction to make. I do search all MIME
sections, including non text/plain. If someone has a document attachment
with a textual phrase, and requests a search for that phrase, it would
certainly be useful if that message had a hit.
> By the way, does Courier implement the specification's formal syntax at
> long last? Or does Courier still take the position that it refuses to
> comply with selected areas of the specification since that would render
> its code into "spaghetti"?
Non-sequitur.
>> the majority of
>> IMAP mail clients already cache headers. Name them: Outlook/Outlook
>> Express, Netscape/Mozilla.
>
> So POP3 clients hacked to babble IMAP represent the "majority" of clients,
Well, the sad truth of life is that they do. Bad-mouthing them is not
going to change that. Yes, my dear, all those naughty clients that are
derisively described as 'POP3 clients hacked to babble IMAP' are, in fact,
what most people use. Life's not perfect. It never was.
> and are the only ones for which a server should optimize??
I don't know about you, but it makes perfect sense to me to optimize for
the most common usage case.
If, and when, the majority of the IMAP clients begin to behave differently,
say line Pine, for example, then it would certainly make sense to change
some things.
>> Jan Kybic's needs are rather
>> unique, and are not representative of the needs of an average IMAP user.
>
> So the needs of a user who uses IMAP the way it is intended is "unique"
> and "not representative"?
I doubt that Aunt Matilda, and Uncle Zeke, with their Internet E-mail
account, have a 10,000-message archive IMAP folder, with a frequent need to
search it.
>> You are just making a mistake thinking that every IMAP mail client in
>> the world works just like Pine.
>
> Every good IMAP client in the world works in a manner similar to Pine.
Well, then, there's just not many "good" IMAP clients in the world out
there.
> The future belongs to those clients. The fact that some vendors
> distributed crappy clients doesn't mean that servers should optimize for
> them.
That's fine by me. I have no problem with anyone optimizing their server
for Pine. It's a free world. However, I do think that large mail plants,
serving tens/hundreds of thousands of accounts won't exactly object to
getting a few more bangs for the buck, when it comes to what most of their
customers use.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE76LC/3ejdWUS0ltARAghnAJ9CXpI6xI9cT/53xYyJBlDtfAMNAQCgkPze
3ofyTee4V2Il45TuEqOUxMU=
=eCuS
-----END PGP SIGNATURE-----
bo
>currently Courier-IMAP. I frequently search for old mails with
>commands such as 'SEARCH SINCE 1-Oct-2001 FROM jan TO jurgen' but they
>seem to take eternity, I think the server just goes through all the
>messages one by one.
This is because that is what you told it to do!
>Would you know about an IMAP server which stores important information
>about messages (data, from, to, subject) in some sort of a database so
>that the searches are quicker?
That kind of functionality comes at a price (currently). You got the
source for Courier - why don't you do it?
Bo
Jan Kybic
> >> I put all my mail (now about 30MB) into a local IMAP server,
> >> currently Courier-IMAP. I frequently search for old mails with
> >> commands such as 'SEARCH SINCE 1-Oct-2001 FROM jan TO jurgen' but they
> >> seem to take eternity, I think the server just goes through all the
> >> messages one by one.
> >
> > That's the price you pay for the maildir format used by Courier.
> >
> >> Would you know about an IMAP server which stores important information
> >> about messages (data, from, to, subject) in some sort of a database so
> >> that the searches are quicker?
> >
> > Cyrus.
Are you sure Cyrus does it? I did not find anything about it in the
documentation. My first attempt to compile it failed, but I am willing
to try again if it solves my problem.
> > Or use UW, which uses flat files that are much faster to search.
> Courier beats UW when searching large mailboxes, on mid-sized hardware:
I do not think it matters, both are going to get uncomfortably slow
when the number of messages grows. Currently, the search of about 30MB
in about 3000 mail messages takes sometimes several minutes on a Pentium II
computer, which is just too slow for me.
I am convinced the only solution is to store the important headers,
possibly with the messages itself, in some database. This has been
implemented with Python and MySQL or Postgress. There is (mail2db,
ftp://ftp.tummy.com/pub/tummy/Mail2DB/) and think the project is
called something like PySQLmail or SQLmail (to check) but there is no
IMAP server interface. I am willing to try to do it myself but I would
prefer to use an existing solution, if available.
> As far as caching mail headers go, again, a real life investigation would
> uncover some interesting surprises: such as the fact that the majority of
> IMAP mail clients already cache headers. Name them: Outlook/Outlook
> Express, Netscape/Mozilla. All of them cache headers. And that takes care
I agree that cacheing headers of the mails read in the same session is
a good thing. However, I do not think the mail client should cache all
the headers of all the mail you ever received, which is what I would
need when searching for some old mail - there are just way too
many. As far as I understood the IMAP philosphy, this should be the
job of the server.
I agree that you can (and should) divide your mail into folders. But
with the time, you will either have too many folders or too many
messages in each of them anyway. Moreover, I sometimes want to search
on subject, sometimes on a person, sometimes on a date - this
flexibility cannot be offered by folders only.
> The only potential savings (as opposed to technically sophisticated
> algorithms that were written only to provide material for a dissertation
> paper, but serve no useful real-world purpose otherwise) from caching mail
> headers can come about if the server has sufficient intelligence to notice
> which mail headers the IMAP client usually asks for, and automatically
> cache those headers, in advance, on all newly arrived mail, anticipating
> that the mail client will request them in the future.
I do not require any artificial intelligence. The set of headers to
search on can be determined in advance, for example: from, to, cc,
bcc, date, subject. I am willing to accept the slow search in the
unlikely event of wanting to search on other criteria.
Mark Crispin
> Are you sure Cyrus does it? I did not find anything about it in the
> documentation. My first attempt to compile it failed, but I am willing
> to try again if it solves my problem.
Yes, Cyrus's mailbox format maintains metadata sufficient to answer your
"SEARCH SINCE 1-Oct-2001 FROM jan TO jurgen" without having to look at the
message files.
Once you do one search like this in UW, subsequent searches of a similar
nature are instantaneous since UW discovered all the necessary metadata in
the first search and now has it cached. Thus, the search would be
completely in memory without looking at the disk at all.
> I do not think it matters, both are going to get uncomfortably slow
> when the number of messages grows. Currently, the search of about 30MB
> in about 3000 mail messages takes sometimes several minutes on a Pentium II
> computer, which is just too slow for me.
That is too slow for most people! I've never had a 30MB/3000 message
search take several minutes, not even on a 25MHz 68040 which is much
slower than a Pentium II.
> I am convinced the only solution is to store the important headers,
> possibly with the messages itself, in some database.
Yup. Cyrus doesn't store messages in the database, but it does store the
metadata there. Exchange uses a database for both (of course, that
database is MS proprietary).
> I agree that cacheing headers of the mails read in the same session is
> a good thing.
A server is pretty much forced to cache metadata if its going to have any
reasonable performance, especially when multiple sesions are done per
search.
> However, I do not think the mail client should cache all
> the headers of all the mail you ever received, which is what I would
> need when searching for some old mail - there are just way too
> many. As far as I understood the IMAP philosphy, this should be the
> job of the server.
Exactly right!
The idea of "make the client cache" is based upon the POP3 model and an
implicit presumption that users only use a single PC and a PC only has a
single user. The soaring popularity of web-based mail should have
thoroughly debunked that notion.
There will always be a market for web-based mail; for a significant
portion of the user community it is the right thing. However, there's
also a significant portion of the user community which uses web-based mail
as a substitute for a decent GUI that doesn't require the client to cache
(Pine has grabbed the user base that doesn't insist upon a GUI).
Sam
Hash: SHA1
In article <Pine.NXT.4.41.011107...@tomobiki-cho.cac.washington.edu>,
Mark Crispin <m...@CAC.Washington.EDU> writes:
> On 7 Nov 2001, Jan Kybic wrote:
>
>> However, I do not think the mail client should cache all
>> the headers of all the mail you ever received, which is what I would
>> need when searching for some old mail - there are just way too
>> many. As far as I understood the IMAP philosphy, this should be the
>> job of the server.
>
> Exactly right!
>
> The idea of "make the client cache" is based upon the POP3 model and an
> implicit presumption that users only use a single PC and a PC only has a
> single user.
It is also based on the requirement to support offline/disconnected mode,
and be able to resynchronize at a later time. As long as
offline/disconnected mode is needed, clients have no choice but to cache
mail headers, in order for them to actually implement offline operations.
Sure, go ahead and try to implement an offline/disconnected IMAP client,
working with UIDs only. You'll certainly be able to do a lot offline,
working with just the UIDs.
Therefore (grandiose theories notwithstanding) personal mail clients that
attempt to provide any kind of reasonable mail functionality will always
need to cache mail headers. Most will also cache mail bodies.
Netscape/Mozilla caches everything it reads from the server. Viewing a
message with Netscape/Mozilla will pull it from the server and save the
message in a local cache. Reopening the message will hit the local cache,
and not go back to the server. People with fast Internet circuits tend to
forget that many folks still use slow temporary Internet dialups.
For this reason, Netscape/Mozilla users will nearly always be able to
review their mailbox in disconnected/offline mode, to some degree.
Therefore, as long as mail is saved locally, I see no reason not to read
the cache in order to satisfy an IMAP request, even if that goes against a
preconceived notion how an ideal IMAP client should work, in a perfect
world.
Fortunately, it appears that folks who actually write mail clients do not
place much weight into hypothetical designs of utopian IMAP clients.
Instead, they tend to focus on real-world functionality; and since mail
headers and/or mail content needs to be cached anyway, subsequent requests
will go to the local cache. As a result of that, the IMAP client is not
likely to ever ask for the same IMAP metadata again, and the logical
conclusion is that caching them on the server is nothing but a waste of CPU
and disk space, in this instance. Q.E.D.
I'm pretty sure Outlook works the same way, as well as any IMAP client that
claims to support offline/disconnected mode. So that pretty much takes
care of a crushing majority of IMAP mail clients in use today.
My analysis indicates that this is one of the reasons why the UW-IMAP
server has frequent scalability issues with large folders, in many
environments. It demands a large resource footprint due to caching of IMAP
metadata which the mail client will not ever need again (and in many cases
won't even ask for it in the first place).
RAM is a scarce, limited, resource. People who need to provide mail
services to a large client base need to be able to support as many client
sessions as possible, with a fixed amount of system RAM. They are likely
to pewdwe supporting a larger number of concurrent clients, with each
request taking a barely perceptible fraction of a second longer to
complete, than opting for the server to acknowledge requests instantly, but
only be able to support half as many clients before running out of RAM and
keeling over.
Of course, running a metadata cache is certainly a valid solution for the
occasional situation where one needs to be able to frequently sift through
a large mail folder, as quickly as possible. But, as I said, I do not
believe that this represents typical mail client usage, so it is perfectly
reasonable to install a special-purpose server for that particular
situation.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE76b4l3ejdWUS0ltARAq0RAJ9vWBojH8CQH02pHhyLfoIEGRuNsACeKUMO
e7fHRaKQKHMzXJrYA9NP1g0=
=Dw4N
-----END PGP SIGNATURE-----
arvidjaar
"Sam" <s...@email-scan.com> wrote in message
news:courier.3BE9...@ny.email-scan.com...
>
> I'm pretty sure Outlook works the same way, as well as any IMAP client
that
> claims to support offline/disconnected mode. So that pretty much takes
> care of a crushing majority of IMAP mail clients in use today.
>
Outlook does not even try to connect to IMAP server for search - all
searching is limited to locally cached data. It is the worst IMAP client I
have seen - it is very good example of "POP client speaking IMAP".
It should resort to local cache in disconnected mode and normal IMAP query
for online mode.
=arvi=
Marijn Ros
> In article <Pine.NXT.4.41.011106...@tomobiki-cho.cac.washington.edu>,
> Mark Crispin <m...@CAC.Washington.EDU> writes:
>
> > 7) If Courier does not obtain metadata, decode encodings, and
> > search only the proper textual segments of messages, then what
> > validity does the comparison have? A proper comparision would be
> > against fgrep. How does Courier fare in subsequent searches?
>
> N/A.
>
> You know, you're not the only person in the world who knows how to
> parse MIME messages.
>
> Actually I do have one small correction to make. I do search all
> MIME sections, including non text/plain. If someone has a document
> attachment with a textual phrase, and requests a search for that
> phrase, it would certainly be useful if that message had a hit.
Searching through text/* would be anough for me, but who am I?
> >> the majority of IMAP mail clients already cache headers. Name
> >> them: Outlook/Outlook Express, Netscape/Mozilla.
> >
> > So POP3 clients hacked to babble IMAP represent the "majority" of
> > clients,
>
> Well, the sad truth of life is that they do. Bad-mouthing them is
> not going to change that. Yes, my dear, all those naughty clients
> that are derisively described as 'POP3 clients hacked to babble
> IMAP' are, in fact, what most people use. Life's not perfect. It
> never was.
You're right about that. However, why would you reward flawed
clients by tuning your server specifically to their needs? If you
value good software as much as I do, you would reward the conforming
clients, while trying not to block the other clients completely.
> > and are the only ones for which a server should optimize??
>
> I don't know about you, but it makes perfect sense to me to optimize
> for the most common usage case.
And it makes perfect sense to me to expect that a program follows the
specification it claims to follow.
> If, and when, the majority of the IMAP clients begin to behave
> differently, say line Pine, for example, then it would certainly
> make sense to change some things.
I don't know how pine behaves with respect to IMAP. The last (and
first) time I used pine (4.10 I guess, it was one of the first
versions with IMAP-support) with an IMAP-server, it got confused over
directories on an Exchange server. At that time, I didn't trust either
program with respect to IMAP, so I chose to stay with the local
mail-spool, which pine used as I wanted.
> >> Jan Kybic's needs are rather unique, and are not representative
> >> of the needs of an average IMAP user.
> >
> > So the needs of a user who uses IMAP the way it is intended is
> > "unique" and "not representative"?
>
> I doubt that Aunt Matilda, and Uncle Zeke, with their Internet
> E-mail account, have a 10,000-message archive IMAP folder, with a
> frequent need to search it.
I doubt Aunt Matilda, and Uncle Zeke, are the persons IMAP was
originally designed for. POP worked fine for them: simply to download
all the mail when they want.
> > The future belongs to those clients. The fact that some vendors
> > distributed crappy clients doesn't mean that servers should
> > optimize for them.
>
> That's fine by me. I have no problem with anyone optimizing their
> server for Pine. It's a free world. However, I do think that large
> mail plants, serving tens/hundreds of thousands of accounts won't
> exactly object to getting a few more bangs for the buck, when it
> comes to what most of their customers use.
What businesses do, is their problem. However, this whole thread seems
to revolve around the basic problem that knowledge about the design
decisions behind programs are essential for making your own decisions
using that software. That way you are able to estimate long-term
effects of the programs at hand.
I wonder, does UW really optimize it's IMAP-server especially for it's
own IMAP-client, is it a by-product of differing interpretations of the
specification, or are their programs really closer to the
specifications.
Bye,
Marijn
Mark Crispin
> I don't know how pine behaves with respect to IMAP. The last (and
> first) time I used pine (4.10 I guess, it was one of the first
> versions with IMAP-support) with an IMAP-server, it got confused over
> directories on an Exchange server.
Pine supported IMAP for a long time before 4.10, for at least 10 years.
In fact, I don't think that a non-IMAP version of Pine was ever released
to the outside world, since IMAP support was added during the development
of Pine 1.0.
Exchange's IMAP support had some teething problems, but those all should
be ancient history.
> At that time, I didn't trust either
> program with respect to IMAP, so I chose to stay with the local
> mail-spool, which pine used as I wanted.
I don't know how you got the idea that Pine was untrustworthy with respect
to IMAP. Pine is the single most trustworthy client with respect to IMAP.
Not surprising, since the person who wrote Pine's IMAP handling code also
invented IMAP and wrote the IMAP specification.
That doesn't mean that there aren't other trustworthy IMAP clients. There
are several.
> I wonder, does UW really optimize it's IMAP-server especially for it's
> own IMAP-client,
The exact opposite is true. The problem is other clients optimizing for a
subset of servers.
The UW IMAP server absolutely conforms to the IMAP specification. It is
not "optimized especially for Pine."
Rather, Pine is optimized especially for IMAP. Pine will work well with
*any* conforming IMAP server. Pine's design was strongly influenced by
IMAP from its inception, and IMAP frequently dictated how Pine would
behave in any given situation.
Whenever Pine accesses POP3 or NNTP mail stores, it treats these as a
crippled IMAP. The one concession that Pine makes for these other
protocols is that it knows about NNTP overviews.
The corrolary is that Pine does not work well with IMAP servers that do
not conform. Pine makes extensive use of all of IMAP's facilities. It is
a good bet that if a capability is in the IMAP specification, Pine uses
it.
Certain IMAP servers are shoddy in their adherance to the IMAP syntax, or
do not implement certain mandatory aspects of IMAP, with such flimsy
justifications as "Netscape doesn't need it, so we don't need to support
it." One vendor openly says that they only support their IMAP server with
Netscape.
The UW IMAP server in its default configuration is strictly compatible
with legacy UNIX mail stores. This means that it has design tradeoffs
that would not have been made if compatibility with legacy UNIX mail
stores was not an issue. Most other servers are completely incompatible
with the past; you must create your own private mail store for IMAP that
can not be accessed by legacy software.
Some clients other than Pine make assumptions about IMAP servers that are
not justified by the IMAP specification. Those clients only talk well to
servers which match those assumptions (curiously, including servers from
from the same vendor). Typically those assumptions preclude legacy mail
stores on UNIX systems.
> is it a by-product of differing interpretations of the
> specification, or are their programs really closer to the
> specifications.
The specification is unambiguous as to syntax and server requirements.
Unfortunately, as noted above, some client and server implementations
either do not obey these requirements, or make faulty assumptions.
Sam
Hash: SHA1
In article <87k7wz6...@214pc221.sshunet.nl>,
Marijn Ros <j.m...@hccnet.nl> writes:
>> Well, the sad truth of life is that they do. Bad-mouthing them is
>> not going to change that. Yes, my dear, all those naughty clients
>> that are derisively described as 'POP3 clients hacked to babble
>> IMAP' are, in fact, what most people use. Life's not perfect. It
>> never was.
>
> You're right about that. However, why would you reward flawed
> clients by tuning your server specifically to their needs? If you
That is a completely separate issue. I've been riding Mozilla's ass for
about two years now, regarding their IMAP client keeling over in certain
situations. They finally closed that bug, supposedly because its now fixed
in the nightly builds. I haven't verified that yet, personally, but I have
no reason to doubt it. Still, other people are still yelling at them
regarding other things. See bug #90494, for example. It warms my heart
seeing stuff like that -- people telling Mozilla that it's stupid to open
five concurrent connections to the server, and there's absolutely no good
reason to do it.
But that is a completely separate issue from implementing a bunch of
necessary bloat solely for the purpose of satisfying some ideal of a
perfect IMAP client, when it would only benefit a statistical blip on the
IMAP client base radar screen. I really don't have that much time to
waste. If I see that the most popular IMAP clients out there would benefit
from header caching, or something else, then I'll do it. But right now
they don't, so I won't.
> value good software as much as I do, you would reward the conforming
> clients, while trying not to block the other clients completely.
Mozilla is really a fairly decent client, except for one or two things. I
have some concerns about recent Outlook breakage that I've seen; but it
looks to me like Mozilla is slowly, but surely, cleaning up their remaining
trouble spots.
>> I doubt that Aunt Matilda, and Uncle Zeke, with their Internet
>> E-mail account, have a 10,000-message archive IMAP folder, with a
>> frequent need to search it.
>
> I doubt Aunt Matilda, and Uncle Zeke, are the persons IMAP was
> originally designed for. POP worked fine for them: simply to download
> all the mail when they want.
You'd be surprised at the growing number of Joe Sixpacks who are taking
advantage of IMAP offerings from their Internet providers, and choosing
IMAP over POP3. I think that's as a result of a growing percentage of an
average mailbox being junk, and using IMAP lets them trash the mail without
having to open it and download it. Then, once they open the mail,
Netscape/Mozilla or Outlook will automatically cache it locally, so then it
becomes not much different from a POP3 environment.
> I wonder, does UW really optimize it's IMAP-server especially for it's
> own IMAP-client, is it a by-product of differing interpretations of the
> specification, or are their programs really closer to the
> specifications.
It's a perfectly natural outcome when you work with both the client and the
server endpoints of the same bit pipe: each one ends up being a better fit
for its peer. It's not a matter interpretation, but in IMAP you have
several different ways of accomplishing essentially the same thing - many
commands accomplishing similar tasks, differing only in minor details. So
it shouldn't be much of a surprise with both pine and uw-imap having the
same preferential set of commands that they like.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE77JzO3ejdWUS0ltARAnhvAJ9Uq2Jrmbeve4a9huGKGIvf+odOqQCeP8Bl
6nMPFEfhGskahNfDEw081yE=
=v8B3
-----END PGP SIGNATURE-----
Sam
Hash: SHA1
In article <9sd8j2$o18$1...@news.mch.sbs.de>,
"arvidjaar" <cku...@yahoo.com> writes:
Well, I don't use Outlook myself. Much. However, I'm surprised to hear
that. The thing about Outlook is that its interface exemplifies the
patronizing and arrogant attitude that Microsoft holds for an average
Windows user. The software acts like the user is a complete idiot, and
needs to have his nose wiped, spoon-fed, and have his diaper changed:
pretty bright colors, moronic things like 'friendly error messages', and
names of options that give you a nice, warm, cozy feeling but absolutely no
clue what those options are really supposed to do (example: "synchronize
all folders" really means "attempt to DOS-attack the server by opening a
couple of hundred simultaneous logins").
Anyway, this is probably an option hidden five layers deep behind some
menu, or something.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE77J3c3ejdWUS0ltARAoBVAJ9zDJVsdmHgVbB7czgFMDOx+NPdwQCfV+ld
/9WCzAJIR1V9rv1DsqMP8FA=
=9fKi
-----END PGP SIGNATURE-----
Jeremy Howard
> In article <9sd8j2$o18$1...@news.mch.sbs.de>,
> "arvidjaar" <cku...@yahoo.com> writes:
> > Outlook does not even try to connect to IMAP server for search - all
> > searching is limited to locally cached data. It is the worst IMAP client
I
> > have seen - it is very good example of "POP client speaking IMAP".
> >
>
> Anyway, this is probably an option hidden five layers deep behind some
> menu, or something.
>
annoying. All they use the server for is to download headers and then bodies
if requested. They don't know how to just download the inline part (they
always download attachments too). They do all sorting and searching on the
client side. However they do support disconnected operations, which is a
start...
Jeremy Howard
"Sam" <s...@email-scan.com> wrote in message
news:courier.3BEC...@gwl.email-scan.com...
> from header caching, or something else, then I'll do it. But right now
> they don't, so I won't.
>
interface to an IMAP server. We use Cyrus for this purpose and it works
great!
> Mozilla is really a fairly decent client, except for one or two things. I
> have some concerns about recent Outlook breakage that I've seen; but it
> looks to me like Mozilla is slowly, but surely, cleaning up their
remaining
> trouble spots.
>
Mozilla still has trouble with Cyrus, AFAIK--you have to manually tell it
that 'Sent' and 'Trash' are under INBOX rather than at the top of the tree.
> You'd be surprised at the growing number of Joe Sixpacks who are taking
> advantage of IMAP offerings from their Internet providers, and choosing
> IMAP over POP3. I think that's as a result of a growing percentage of an
> average mailbox being junk, and using IMAP lets them trash the mail
without
> having to open it and download it. Then, once they open the mail,
> Netscape/Mozilla or Outlook will automatically cache it locally, so then
it
> becomes not much different from a POP3 environment.
>
Yep, it's great the way IMAP is becoming more popular. I run a publically
available IMAP service at http://fastmail.fm , and evangelise how great IMAP
is wherever I can. See for example our FAQ:
http://www.fastmail.fm/docs/faqparts/ExternalMail.html
Slowly I'm starting to see 'average users' switching across to IMAP, and
when they do they almost always love it. Unfortunately though there's still
no really good easy-to-use client. I refer our most technical users to
Mulberry, but we still get reports that they take 2-3 solid days to get the
hang of it properly. Most Windows folks we still refer to Outlook Express.
But it does so many things so stupidly that it can be offputting--for
instance the way when you move a message to another folder, it removes it
from it's local cache and re-downloads it when you view it in the other
folder, which drives modem users crazy! Intermediate users we suggest
Mozilla to, but almost no-one installs it because the web-site is very
newbie unfriendly.
BTW, I should mention in fairness that there are other public IMAP providers
too, subdimension.com and myrealbox.com being the most frequently mentioned
that I've seen. Although myrealbox.com has seen some action on this NG for
having a pretty broken IMAP implementation...
Marijn Ros
> On 9 Nov 2001, Marijn Ros wrote:
> > I don't know how pine behaves with respect to IMAP. The last (and
> > first) time I used pine (4.10 I guess, it was one of the first
> > versions with IMAP-support) with an IMAP-server, it got confused over
> > directories on an Exchange server.
>
> Pine supported IMAP for a long time before 4.10, for at least 10 years.
> In fact, I don't think that a non-IMAP version of Pine was ever released
> to the outside world, since IMAP support was added during the development
> of Pine 1.0.
Ah, then our sysadmins probably hid the possibility from us, as there
was no IMAP-server available anyway.
> Exchange's IMAP support had some teething problems, but those all should
> be ancient history.
It was three or four years ago. All my friends switched to mutt for
IMAP, but I stayed with pine and direct spool-file handling (despite
gentle pushing of IMAP by the sysadmins).
> > At that time, I didn't trust either program with respect to IMAP,
> > so I chose to stay with the local mail-spool, which pine used as I
> > wanted.
>
> I don't know how you got the idea that Pine was untrustworthy with
> respect to IMAP. Pine is the single most trustworthy client with
> respect to IMAP.
The basic line of thought was:
1) I need to switch, I don't like that.
2) I haven't used the functionality before, so I don't trust that.
3) The programs don't interoperate as I want, I don't like that.
4) I can't seem to find out which program is wrong, I don't like that.
It was not that I thought pine to be especially untrustworthy, more
that I didn't think it as especially trustworthy. Not very surprising,
as it didn't function as I wanted and I was unable to find out at that
time whether it was pine or Exchange being flawed.
> Not surprising, since the person who wrote Pine's IMAP handling code
> also invented IMAP and wrote the IMAP specification.
I didn't have that information at that time.
> > I wonder, does UW really optimize it's IMAP-server especially for
> > it's own IMAP-client,
>
> The exact opposite is true. The problem is other clients optimizing
> for a subset of servers.
I was afraid of that.
<snip detailed explanation>
> > is it a by-product of differing interpretations of the
> > specification, or are their programs really closer to the
> > specifications.
>
> The specification is unambiguous as to syntax and server
> requirements.
That's nice to know. I like clear specifications, especially or
clear-text protocols. It make it possible to use the protocols by hand
if needed.
Thanks for the thorough explanation of the views towards the IMAP
standard regarding interoperability between UW-products and the rest
of the world. And I hope I didn't offend you too much by not trusting
a feature of pine at first sight.
Bye,
Marijn
Marijn Ros
> Yep, it's great the way IMAP is becoming more popular. I run a
> publically available IMAP service at http://fastmail.fm , and
> evangelise how great IMAP is wherever I can.
How do you manage to mention it now, just when I'm looking for an
inexpensive ($1/month) IMAP provider (in the Netherlands, as that
eases bank-transfers for payment).
Does anyone know how to find service providers providing a
mail-address with IMAP access with filters and about 5 MB of
disk-space? I tried web-searching with google, but the queries either
returned over 1000 entries (of which the first 30 were not useful) or
none.
Thanks in advance,
Marijn
Mark Crispin
> Thanks for the thorough explanation of the views towards the IMAP
> standard regarding interoperability between UW-products and the rest
> of the world.
No problem! Glad to help.
> And I hope I didn't offend you too much by not trusting
> a feature of pine at first sight.
I wasn't offended at all. It was more of a shudder at the thought of what
kind of misinformation would get spread around when I'm no longer around
to correct it! :-)
Mike Brodbelt
> <cc'd to poster>
> "Sam" <s...@email-scan.com> wrote in message
> news:courier.3BEC...@gwl.email-scan.com...
>>
> Mozilla still has trouble with Cyrus, AFAIK--you have to manually tell it that
> 'Sent' and 'Trash' are under INBOX rather than at the top of the tree.
Netscape 6 releases also suffer from this - you get errors trying to copy sent
messages to the sent mail folder until you manually adjust it - irritating.
> Slowly I'm starting to see 'average users' switching across to IMAP, and when
> they do they almost always love it. Unfortunately though there's still no
> really good easy-to-use client. I refer our most technical users to Mulberry,
> but we still get reports that they take 2-3 solid days to get the hang of it
> properly.
I've looked at quite a few clients these days, and most of them are poor.
Mulberry is technically good - it supports numerous standards not easily
available elsewhere, and is solid. However, I personally find the interface
clunky and "old" looking, and, as it not not free (as in beer) I think it has
little hope of wide adoption. People aren't interested in paying for desktop
mail clients these days, there is a wide choice of free ones, and they do IMAP
"well enough" for most of the people, most of the time....
> Most Windows folks we still refer to Outlook Express. But it does so many
> things so stupidly that it can be offputting--for instance the way when you
> move a message to another folder, it removes it from it's local cache and
> re-downloads it when you view it in the other folder, which drives modem users
> crazy! Intermediate users we suggest Mozilla to, but almost no-one installs it
> because the web-site is very newbie unfriendly.
Netscape 6.2 is really not at all bad. It's a memory hog, but it's a nice mail
client, and behaves fairly sensibly most of the time. On Linux, Evolution is
rapidly turning into a very nice client indeed - support for SSL, CRAM-MD5
authentication, and a slick interface.
> BTW, I should mention in fairness that there are other public IMAP providers
> too, subdimension.com and myrealbox.com being the most frequently mentioned
> that I've seen. Although myrealbox.com has seen some action on this NG for
> having a pretty broken IMAP implementation...
I actually think that doing what you do, and providing a public IMAP service ff
Cyrus, with web access, and filtering, is a very nice service. It's probably one
of the few areas where people will be willing to pay for a decent system for the
forseeable future. I'd be signing up for something like it if I didn't have
broadband access...
Mike.
arvidjaar
>> Anyway, this is probably an option hidden five layers deep behind some
>> menu, or something.
>>
> No. Outlook and OE only know how to search the local cache. It's truely
> annoying. All they use the server for is to download headers and then
> bodies if requested. They don't know how to just download the inline part
> (they always download attachments too). They do all sorting and searching
> on the client side. However they do support disconnected operations, which
> is a start...
Outlook 2002 (and IIRC Outlook 2000 as well) download attachments on
demand. Cannot say about OE as I never actually used it.
I wonder, what other IMAP plugins for Outlook do, if they really support
complete set of IMAP operations. But I am not sure if they even exist now,
when Outlook 2002 suports all types of mail access, no more of this stupid
IMO vs Corporate battle.
=arvi=
Jeremy Howard
> Outlook 2002 (and IIRC Outlook 2000 as well) download attachments on
> demand. Cannot say about OE as I never actually used it.
>
We try and keep docs for setting up each major IMAP client with fastmail.fm
such as this page for OE here:
http://www.fastmail.fm/docs/imap/imap-oe.html
We don't have access to XP at the moment. Any chance that some nice person
could do screen-shots of the config screens for Outlook 2002 IMAP +
fastmail.fm + (preferably) SSL, and send them to webmasterATfastmailDOTfm?
Jeremy Howard
"Marijn Ros" <j.m...@hccnet.nl> wrote in message
news:87lmheo...@214pc221.sshunet.nl...
> "Jeremy Howard" <jhowardNOSPA...@fastmail.fm> writes:
>
> > Yep, it's great the way IMAP is becoming more popular. I run a
> > publically available IMAP service at http://fastmail.fm , and
> > evangelise how great IMAP is wherever I can.
>
> How do you manage to mention it now, just when I'm looking for an
> inexpensive ($1/month) IMAP provider (in the Netherlands, as that
> eases bank-transfers for payment).
>
BTW, why do you need an Netherlands provider? What's wrong with credit card
or PayPal, or using a free provider?
> Does anyone know how to find service providers providing a
> mail-address with IMAP access with filters and about 5 MB of
> disk-space? I tried web-searching with google, but the queries either
> returned over 1000 entries (of which the first 30 were not useful) or
> none.
>
A good place to go for this information is http://www.emaildiscussions.com,
which is the most active forum I know of for discussing email issues from a
user perspective. See for example this thread discussing publicly accessible
IMAP providers:
http://www.emailaddresses.com/forum/showthread.php?threadid=1125
Usenet regulars may find the colorful web interface initially disconcerting
(I've heard it described as 'unprofessional') but the level of interest,
knowledge and commitment from the regular posters there is very impressive.
BTW, fastmail.fm provides exactly what you describe for free (you get 100MB
disk space, although that will be dropping to 10MB in a few months unless
you pay).
Marijn Ros
> <cc'd to poster>
> "Marijn Ros" <j.m...@hccnet.nl> wrote in message
> news:87lmheo...@214pc221.sshunet.nl...
> > "Jeremy Howard" <jhowardNOSPA...@fastmail.fm> writes:
> >
> > > Yep, it's great the way IMAP is becoming more popular. I run a
> > > publically available IMAP service at http://fastmail.fm , and
> > > evangelise how great IMAP is wherever I can.
> >
> > How do you manage to mention it now, just when I'm looking for an
> > inexpensive ($1/month) IMAP provider (in the Netherlands, as that
> > eases bank-transfers for payment).
> >
> I could tell you how I did it, but I'd have to kill you ;-)
>
> BTW, why do you need an Netherlands provider? What's wrong with credit card
> or PayPal, or using a free provider?
I don't have a creditcard (I had one for 4 years, but only used it
twice: once to phone home and once to pay for car-repairs of a
friend), so that would add another $20 per year. I don't trust online
banking systems yet (I don't trust anyone, actually, but people who
get paid by me are better). And I want to pay for the service I get,
if only to be able to vote with my money instead of only with my feet.
And of course a provider nearby also means that RTT is shorter
(america adds 100ms) and a provider in your own country means that it
is automatically clear under which legal system the contract
falls. Unfortunately, in the Netherlands all e-mail traffic (all
internet trafic, actually, but with a special mention of e-mail) must
be tapable. So a provider overseas with IMAPS and SMTP-over-SSL would
be cool.
> > Does anyone know how to find service providers providing a
> > mail-address with IMAP access with filters and about 5 MB of
> > disk-space? I tried web-searching with google, but the queries either
> > returned over 1000 entries (of which the first 30 were not useful) or
> > none.
>
> A good place to go for this information is
> http://www.emaildiscussions.com, which is the most active forum I
> know of for discussing email issues from a user perspective. See for
> example this thread discussing publicly accessible IMAP providers:
> http://www.emailaddresses.com/forum/showthread.php?threadid=1125
I'll check that, thanks.
> Usenet regulars may find the colorful web interface initially
> disconcerting (I've heard it described as 'unprofessional') but the
> level of interest, knowledge and commitment from the regular posters
> there is very impressive.
The pages look fine in lynx. And following links, I found
http://www.imap.org/products/providers.html, with some dutch providers
as well. DDS is probably good (they were in 1994/1995 when they
offered a telnet connection dropping you into pine for free), alhough
twice as expensive as I had in mind.
> BTW, fastmail.fm provides exactly what you describe for free (you
> get 100MB disk space, although that will be dropping to 10MB in a
> few months unless you pay).
Yes I noticed that. And 10MB should be anough. I try not to keep too
much mail around. Maybe, I'll create an account at your service, just
to play with it for a while. My current mail-account stops first of
january.
Thanks for the information,
Marijn
arvidjaar
"Jeremy Howard" <jhowardNOSPA...@fastmail.fm> wrote in message
news:UZjH7.190$%M4.2...@nasal.pacific.net.au...
> <cc'd to poster>
If you Cc to somebody please use real address. At least if you want to
receive any reply.
Jeremy Howard
news:9sntsl$aqd$1...@news.mch.sbs.de...
>
> "Jeremy Howard" <jhowardNOSPA...@fastmail.fm> wrote
^^^^^^^^^^^^
> > <cc'd to poster>
>
> If you Cc to somebody please use real address. At least if you want to
> receive any reply.
>
Nancy McGough
> Pine supported IMAP for a long time before 4.10, for at least 10 years.
> In fact, I don't think that a non-IMAP version of Pine was ever released
> to the outside world, since IMAP support was added during the development
> of Pine 1.0.
I just updated my main Pine page so it includes this information
but I'm wondering if I am correct when I say that Pine "was one
of the first IMAP clients" -- is that true? Here's what I've got
on my page now...
History of the Pine Program and Its Name
The University of Washington Office of Computing & Communications
created Pine in 1989 as a user-friendly character-based mail
client for Unix. Pine version 1 was released to the public ten
years ago in 1991 and was one of the first IMAP clients. Since
then it has evolved into a powerful robust customizable
standards-based IMAP and NNTP client that is used by millions of
people around the world. The UW developed the latest version,
4.40, for many flavors of Unix including Mac OS X, and for MS
Windows (called PC-Pine). It has been ported by others to many
systems, including OS/2, BeOS, Amiga, and VMS.
The title of this page, All About PINE: IMAP, NNTP, & ESMTP, and
the signature that I use in public postings might lead you to
believe that the INE in PINE stands for IMAP, NNTP, & ESMTP,
but it doesn't! For all the gory details about the history of
Pine and its name, see Laurence Lundblade's What "Pine" Really
Stands For and the UW's Pine Project History & Pine Release
Chronology & Version Changes.
Note
Pine is actually a package of programs and is sometimes called
"The Pine Message System." The Unix Pine Message System is made
up of the core program, Pine; the pine composer, Pico; and the
pine lister of things, Pilot. The PC-Pine Message System is made
up of Pine, Pico, some DLLs, and uses the MS-Windows file manager
for file management.
> That doesn't mean that there aren't other trustworthy IMAP clients. There
> are several.
What other IMAP clients do you consider trustworthy? Currently I
recommend Pine or Mulberry but I'd like to know what else is
worth recommending. Many people want a GUI IMAP client but don't
want to spend $36 for Mulberry (even though they use their mail
client more than any other program on their system and $36 รท 365
days is less than 10 cents per day!).
Thanks,
Nancy
^x
REFERENCE:
The message I'm replying to -- and this entire thread & group --
may be available at
--
ii Main Pine Page: <http://www.ii.com/internet/messaging/pine/>
Nancy McGough <http://www.ii.com/> Infinite Ink
--= Sent via Pine: IMAP, NNTP & ESMTP for Unix/Win/Mac OS X =--
Mark Crispin
> > "Jeremy Howard" <jhowardNOSPA...@fastmail.fm> wrote
> > > <cc'd to poster>
> > If you Cc to somebody please use real address. At least if you want to
> > receive any reply.
> It's not that hard to figure out how to reply, is it?
That is irrelevant. Other people should not be required to (1) observe
that the email address has been faked and (2) edit it to the correct
address.
It is a fantasy that doing this will make your address any less likely to
get spammed. All it does is make things more difficult for the poor
people who try to respond to you.
Normally, I don't reply to messages with fake email addresses. Such
messages identify a sender who isn't worth replying to.
In any case, your effort to hide your address is futile. This posting
has with your correct address, free for any spam harvester.
Mark Crispin
> I'm wondering if I am correct when I say that Pine "was one
> of the first IMAP clients" -- is that true?
Yes. There were a few IMAP clients before Pine, but Pine is undeniably
the first one that had more than a 2-digit user community.
> What other IMAP clients do you consider trustworthy? Currently I
> recommend Pine or Mulberry but I'd like to know what else is
> worth recommending.
I do not have comprehensive knowledge of all the trustworthy IMAP clients
out there. Mentioning any client by name implies endorsement of that
client; and more importantly implies non-endorsement of other clients.
I do not have comprehensive knowledge of all IMAP clients, and thus do not
want inadvertantly to snub a deserving client out of ignorance.
Consequently, I don't feel comfortable about making such statements,
except of course for Pine.
Lawrence Greenfield
Date: Sat, 10 Nov 2001 20:09:20 +0000
[...]
Netscape 6.2 is really not at all bad. It's a memory hog, but it's a nice mail
client, and behaves fairly sensibly most of the time. On Linux, Evolution is
rapidly turning into a very nice client indeed - support for SSL, CRAM-MD5
authentication, and a slick interface.
It's a pity that Evolution turned down patches to make it optionally
use the Cyrus SASL library, since that impedes those of us who would
like to use Kerberos with it.
Larry
Jason Haar
> One place this is really handy is for implementing webmail clients that
> interface to an IMAP server. We use Cyrus for this purpose and it works
> great!
Again this can be fixed by the webmail software doing the caching. That
leads to *much* better performance than relying on the choice of IMAP server.
IMHO Squirrelmail is an example of a "good" webmail IMAP package that does
just that.
--
Cheers
Jason Haar
Information Security Manager
Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
Jeremy Howard
news:slrn9v096s...@crom.trimble.co.nz...
> On Sat, 10 Nov 2001, Jeremy Howard wrote:
> > One place this is really handy is for implementing webmail clients that
> > interface to an IMAP server. We use Cyrus for this purpose and it works
> > great!
>
> Again this can be fixed by the webmail software doing the caching. That
> leads to *much* better performance than relying on the choice of IMAP
server.
>
and some you don't. For instance we cache folder lists on the server, which
saves a little time. But caching message lists is clearly not a good idea
(since they can be changed by another IMAP client and you need to reflect
that) and caching message contents or MIME structures is not clearly a
benefit either. You can use a no-cache pragma to have the screen cached by
the client. Caching every message on the web server is clearly memory
hungary, so you have to access the server to grab the message--while you're
there you may as well grab the server-cached MIME structure as well.
Otherwise you have to implement some kind of database or shared memory for
MIME structures across your web server processes which is yet another data
store to maintain, which seems a bit pointless when the IMAP server can do
this for you.
Jeremy Howard
news:Pine.NXT.4.41.011112...@Tomobiki-Cho.CAC.Washington.ED
U...
> Normally, I don't reply to messages with fake email addresses. Such
> messages identify a sender who isn't worth replying to.
>
messages identify a sender who isn't worth replying to.
Obviously.
> In any case, your effort to hide your address is futile. This posting
> has with your correct address, free for any spam harvester.
>
I notice that you don't generally cross-post your messages to a large number
of newsgroups. I assume that this is because on don't what to be added to a
lot of blocked senders lists and be subject to a torrent of abuse.
However this behaviour is inconvenient to me because I don't always read the
comp.mail.imap group, and I don't want to miss any of your insightful posts.
Therefore I've reposted the exact headers and body of your last message to
the entire Usenet hierarchy. Given that the damage is now already done, you
may as well cross-post all of your future messages, and avoid the
inconvenience that I face.
PS: The above contains a number of factually incorrect statements in the
interest of developing an analogy. Corrections follow:
- I do actually reply to messages with a 'k' in their headers
- I do actually read comp.mail.imap regularly
- I didn't really repost your message
- I don't really mind that much if I happen to miss one of your posts.
Mike Brodbelt
I'm not sure I see why you can't anyway... Surely you can use, for example, a
Cyrus server that uses SASL to authenticate users via Kerberos, and then have
Evolution auth against that with CRAM-MD5?
It might have been nicer with Kerberos built in to the client, but I would have
thought that you can work with it in a Kerberos environment anyway. Maybe
they'll accept Kerberos patches post version 1 release - I think there's a
certain urgency to get it out of the door as an Outlook killer. I've certaintly
been impressed with the development speed, given the size of the app.
Mike.
Jeremy Howard
news:FAXH7.2014$k55.1...@monolith.news.easynet.net...
Evolution/SASL patch? Is it just postponed until a later release (very
understandable for the reasons Mike mentioned), or did they flat out reject
it for some reason?
Lawrence Greenfield
Date: Tue, 13 Nov 2001 09:21:34 +1100
"Mike Brodbelt" <mike@_nospam_coruscant.demon.co.uk> wrote in message
news:FAXH7.2014$k55.1...@monolith.news.easynet.net...
> I'm not sure I see why you can't anyway... Surely you can use,
> for example, a Cyrus server that uses SASL to authenticate users
> via Kerberos, and then haveEvolution auth against that with CRAM-MD5?
This misunderstands the point of Kerberos. Kerberos needs a
client-side portion to do secure authentication without compromising
your credentials to the server and to do mutual authentication.
[...]
Larry, did the Evolution team give a reason for rejecting your
Evolution/SASL patch? Is it just postponed until a later release (very
understandable for the reasons Mike mentioned), or did they flat out reject
it for some reason?
Yes, the code was rejected due to the licensing on the Cyrus SASL
library, even though the API is standardized between several
implementations (none of the others are free). I've attached an
excerpt of part of this conversation.
Sadly, this means that Evolution can't leverage the preexisting work
that has been done for the Cyrus SASL library.
Larry
> Date: Mon, 18 Dec 2000 10:45:07 -0500
> From: Dan Winship <da...@helixcode.com>
>
> Unfortunately, the Cyrus SASL library's license is not GPL-compatible,
> so it can't be integrated with Evolution. :-/
>
> However, in Evolution 0.8, there is support for Kerberos 4-based IMAP
> authentication, and adding other types shouldn't be hard. I was
> planning at some point to split the code out of the IMAP provider to
> make a "camel-sasl" library or something so that the POP and SMTP
> providers could use it too.
Mark Crispin
is not GPL (it's under a "free fork" license which is considerably more
free than GPL, and permits redistribution under GPL).
SASL authenticators are implemented in a modular fashion in c-client, so
Evolution could leverage the preexisting work in c-client's SASL library
without significantly greater effort than the Cyrus SASL library.
tma...@andrew.cmu.edu
Message
>thought that you can work with it in a Kerberos environment anyway. Maybe
>they'll accept Kerberos patches post version 1 release - I think there's a
>certain urgency to get it out of the door as an Outlook killer. I've certaintl
>y
>been impressed with the development speed, given the size of the app.
FWIW the patches were submitted to the evolution people dec. 18th of last year.
-tim