Sébastien Vauban wrote:
>What would be your pieces of advice in such a case? Do I need to test
>something extra? Get a local imap server? Others (like asking for fixing the
>search on our Courier mail server)?

Well, IMO there might be nothing to "fix" on the server side.
Although a user might expect searches to be fast there is no directive
in the specs about the fastness of the SEARCH command.  This should of
course not prevent you from dropping a mail to the IMAP server admins
about your problem to at least point at this performance issue with
large mailboxes.

At the client side I asked myself why Gnus does not use the cached
message.  Some vague guesses:

> I've checked the cache; in /home/sva/Mail/cache/nnimap+me:INBOX.work, I have a
> copy of the linked email:

>   -rw-r--r-- 1 sva sva   1631 2010-06-28 14:09 28606

Okay, Gnus caches the message but would have to search in all cached
messages for the message id header.  "28606" might be the UID of the
message in the mailbox.  To confirm this login manually and prefix the
search command with "UID"

,----
| 0x3 UID SEARCH HEADER "Message-ID" "871vbrxzo6.fsf@mundaneum.com"
`----

If this search returns 28606 then we can assume that Gnus indeed
caches by UID[1].  This means that Gnus needs to query the server what
the UID of the message with a particular message id is and could than
use the cache.

This is the point where I conclude that there can't be done anything
about it except modifying Gnus' cache mechanism.[2]

So the fall back would be: Not to keep everything in the IMAP mailbox
but expire old messages to a local folder.  Here I have rule that
says: Everything older than 180 days is moved from IMAP inbox to a
local archive folder.  The implications are, of course, that links to
messages older than 180 days break.  To mitigate this I use Namazu[3]
to index my local archives and in case I need to follow such a broken
Org link I could open the link by performing a search for the
message-id first[4].

In the case of Gnus we might modify org-gnus-open to, say, perform a
mairix search for the message id if called with prefix and open the
message in the search result folder.

HTH,
  -- David


[1] Valid strategy because message UID are quite persistent (read:
they are persistent unless a special event that we can ignore for now).

[2] Wanderlust for example does not have this problem because it keeps
an overview of the IMAP mailbox that includes among other things
message-id, uid and subject.

[3] www.namazu.org

[4] WL integrates namazu search folders so there is no need for org-wl
to perform the search, just open such a search folder.
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de