I added 6000 items to a test account.  I pulled down the items with Evolution. 
Evolution did a readCursor call and pulled down all the items correctly. 
Evolution then does a getQuickMessage call for new, modified and all items. 
This is where the problem occurs.  The getQM for all items makes a call to
wpfreadindex.  Wpfreadindex has a limit of roughly 4950 items.

1.  Evolution is making the getQM call to get new items.  This is okay and will
not hit the limit unless they have more than 4950 new items in a folder.
2.  Evolution is making the getQM call to get modified items.  This is okay and
will not hit the limit.  We have added code that tells us to start after a
specific startdate.  They can modify the startDate so they will not hit the limit.

Problem
3.  Evolution is making the getQM call to get all items.  They are doing this so
they can determine what items have been deleted.   This is where the problem
occurs.  Our index read has a 4950 item limit.  If the folder has 6000 items,
Evo will assume that items 5000-6000 have been deleted because they do not get
return information for those items.


Solution to Track Deleted Items
1.  GroupWise Events is the best way to track items that have been deleted.
2.  Another approach is to readCursors with a view of the item id.  Evo can
compare the ids in their store to the ids returned.  I will present this
information in an email and in bugzilla.