From: Andrea R. <rig...@gm...> - 2011-04-23 01:37:00
|
To retrieve new messages from a IMAP folder we use the IMAP SEARCH command, but we limit the messages processed by the query to 1000. This limit is hard-coded and it cannot be changed at runtime. This value is not the best option in some cases, especially for large folders, because we need to submit a query each 1000 messages. The following patch introduces a new option (imapsearchmax) that can be used to change this limit at runtime. So, for example this is what happens with a 3000 messages folder: ... fetchmail: IMAP< A0003 OK [READ-WRITE] INBOX selected. (Success) fetchmail: IMAP> A0004 SEARCH 1:1000 UNSEEN UNDELETED fetchmail: IMAP< * SEARCH fetchmail: IMAP< A0004 OK SEARCH completed (Success) fetchmail: IMAP> A0005 SEARCH 1001:2000 UNSEEN UNDELETED fetchmail: IMAP< * SEARCH fetchmail: IMAP< A0005 OK SEARCH completed (Success) fetchmail: IMAP> A0006 SEARCH 2001:3000 UNSEEN UNDELETED ... With imapsearchmax we could increase the SEARCH limit to a higher value (i.e., 5000) and submit a single query to the server: ... fetchmail: IMAP< A0003 OK [READ-WRITE] INBOX selected. (Success) fetchmail: IMAP> A0004 SEARCH 1:5000 UNSEEN UNDELETED ... I did some tests with my >500000 messages gmail INBOX. The results are reported below: - without the patch: $ time fetchmail -s real 7m1.338s user 0m0.070s sys 0m0.100s - with the patch (using imapsearchmax=1000000) $ time fetchmail -s --imapsearchmax=1000000 real 0m3.099s user 0m0.000s sys 0m0.040s Signed-off-by: Andrea Righi <rig...@gm...> --- conf.c | 1 + fetchmail.c | 7 +++++++ fetchmail.h | 1 + fetchmail.man | 7 +++++++ fetchmailconf.py | 6 ++++++ imap.c | 13 +++++++------ options.c | 7 +++++++ rcfile_l.l | 1 + rcfile_y.y | 3 ++- 9 files changed, 39 insertions(+), 7 deletions(-) diff --git a/conf.c b/conf.c index 5758138..0f968d0 100644 --- a/conf.c +++ b/conf.c @@ -375,6 +375,7 @@ void dump_config(struct runctl *runp, struct query *querylist) numdump("warnings", ctl->warnings); numdump("fetchlimit", ctl->fetchlimit); numdump("fetchsizelimit", ctl->fetchsizelimit); + numdump("imapsearchmax", ctl->imapsearchmax); numdump("fastuidl", ctl->fastuidl); numdump("batchlimit", ctl->batchlimit); #ifdef SSL_ENABLE diff --git a/fetchmail.c b/fetchmail.c index fc39936..0a05bd8 100644 --- a/fetchmail.c +++ b/fetchmail.c @@ -977,6 +977,7 @@ static void optmerge(struct query *h2, struct query *h1, int force) FLAG_MERGE(warnings); FLAG_MERGE(fetchlimit); FLAG_MERGE(fetchsizelimit); + FLAG_MERGE(imapsearchmax); FLAG_MERGE(fastuidl); FLAG_MERGE(batchlimit); #ifdef SSL_ENABLE @@ -1023,6 +1024,7 @@ static int load_params(int argc, char **argv, int optind) def_opts.remotename = user; def_opts.listener = SMTP_MODE; def_opts.fetchsizelimit = 100; + def_opts.imapsearchmax = 1000; def_opts.fastuidl = 4; /* get the location of rcfile */ @@ -1761,6 +1763,11 @@ static void dump_params (struct runctl *runp, ctl->fetchsizelimit, ctl->fetchsizelimit); else if (outlevel >= O_VERBOSE) printf(GT_(" No fetch message size limit (--fetchsizelimit 0).\n")); + if (NUM_NONZERO(ctl->imapsearchmax)) + printf(GT_(" Max number of messages we can process in IMAP SEARCH response is %d (--imapsearchmax %d).\n"), + ctl->imapsearchmax, ctl->imapsearchmax); + else if (outlevel >= O_VERBOSE) + printf(GT_(" No max number of messages for IMAP SEARCH (--imapsearchmax 0).\n")); if (NUM_NONZERO(ctl->fastuidl) && MAILBOX_PROTOCOL(ctl)) { if (ctl->fastuidl == 1) diff --git a/fetchmail.h b/fetchmail.h index f6c6a4e..dce4d7d 100644 --- a/fetchmail.h +++ b/fetchmail.h @@ -360,6 +360,7 @@ struct query int warnings; /* size warning interval */ int fetchlimit; /* max # msgs to get in single poll */ int fetchsizelimit; /* max # msg sizes to get in a request */ + int imapsearchmax; /* max # msg we can process in "SEARCH" response */ int fastuidl; /* do binary search for new UIDLs? */ int fastuidlcount; /* internal count for frequency of binary search */ int batchlimit; /* max # msgs to pass in single SMTP session */ diff --git a/fetchmail.man b/fetchmail.man index 69aa887..4cca19c 100644 --- a/fetchmail.man +++ b/fetchmail.man @@ -811,6 +811,13 @@ messages are downloaded at the start. This option does not work with ETRN or ODMR. For POP3, the only valid non-zero value is 1. .TP +.B \-\-imapsearchmax <number> +(Keyword: imapsearchmax) +.br +Limit the maximum number of messages processed by the IMAP SEARCH query to an +IMAP server. By default, the limit is 1000. If set to 0, the IMAP SEARCH is +applied to all the messages present in the target IMAP folder. +.TP .B \-\-fastuidl <number> (Keyword: fastuidl) .br diff --git a/fetchmailconf.py b/fetchmailconf.py index 2dc02d8..8eec6db 100755 --- a/fetchmailconf.py +++ b/fetchmailconf.py @@ -261,6 +261,7 @@ class User: self.warnings = 3600 # Size warning interval (see tunable.h) self.fetchlimit = 0 # Max messages fetched per batch self.fetchsizelimit = 100 # Max message sizes fetched per transaction + self.imapsearchmax = 1000 # Max number of messages processed by "IMAP SEARCH" self.fastuidl = 4 # Do fast uidl 3 out of 4 times self.batchlimit = 0 # Max message forwarded per batch self.expunge = 0 # Interval between expunges (IMAP) @@ -302,6 +303,7 @@ class User: ('warnings', 'Int'), ('fetchlimit', 'Int'), ('fetchsizelimit', 'Int'), + ('imapsearchmax', 'Int'), ('fastuidl', 'Int'), ('batchlimit', 'Int'), ('expunge', 'Int'), @@ -369,6 +371,8 @@ class User: res = res + " fetchlimit " + `self.fetchlimit` if self.fetchsizelimit != UserDefaults.fetchsizelimit: res = res + " fetchsizelimit " + `self.fetchsizelimit` + if self.imapsearchmax != UserDefaults.imapsearchmax: + res = res + " imapsearchmax " + `self.imapsearchmax` if self.fastuidl != UserDefaults.fastuidl: res = res + " fastuidl " + `self.fastuidl` if self.batchlimit != UserDefaults.batchlimit: @@ -1761,6 +1765,8 @@ class UserEdit(Frame, MyWidget): self.fetchlimit, '30').pack(side=TOP, fill=X) LabeledEntry(limwin, 'Max message sizes to fetch per transaction:', self.fetchsizelimit, '30').pack(side=TOP, fill=X) + LabeledEntry(limwin, 'Max number of messages processed by the IMAP SEARCH query:', + self.imapsearchmax, '30').pack(side=TOP, fill=X) if self.parent.server.protocol not in ('ETRN', 'ODMR'): LabeledEntry(limwin, 'Use fast UIDL:', self.fastuidl, '30').pack(side=TOP, fill=X) diff --git a/imap.c b/imap.c index 1364027..9bd9221 100644 --- a/imap.c +++ b/imap.c @@ -754,14 +754,15 @@ static int imap_idle(int sock) return(ok); } -/* maximum number of numbers we can process in "SEARCH" response */ -# define IMAP_SEARCH_MAX 1000 - static int imap_search(int sock, struct query *ctl, int count) /* search for unseen messages */ { int ok, first, last; char buf[MSGBUFSIZE+1], *cp; + int stride = ctl->imapsearchmax; + + if (stride < 0) + stride = INT_MAX; /* Don't count deleted messages. Enabled only for IMAP4 servers or * higher and only when keeping mails. This flag will have an @@ -771,15 +772,15 @@ static int imap_search(int sock, struct query *ctl, int count) const char *undeleted; /* Skip range search if there are less than or equal to - * IMAP_SEARCH_MAX mails. */ - flag skiprangesearch = (count <= IMAP_SEARCH_MAX); + * imap_search_max mails. */ + flag skiprangesearch = (count <= stride); /* startcount is higher than count so that if there are no * unseen messages, imap_getsizes() will not need to do * anything! */ startcount = count + 1; - for (first = 1, last = IMAP_SEARCH_MAX; first <= count; first += IMAP_SEARCH_MAX, last += IMAP_SEARCH_MAX) + for (first = 1, last = stride; first <= count; first += stride, last += stride) { if (last > count) last = count; diff --git a/options.c b/options.c index aee616b..6c7c612 100644 --- a/options.c +++ b/options.c @@ -50,6 +50,7 @@ enum { LA_SSLCOMMONNAME, LA_SSLFINGERPRINT, LA_FETCHSIZELIMIT, + LA_IMAPSEARCHMAX, LA_FASTUIDL, LA_LIMITFLUSH, LA_IDLE, @@ -120,6 +121,7 @@ static const struct option longoptions[] = { {"batchlimit",required_argument, (int *) 0, 'b' }, {"fetchlimit",required_argument, (int *) 0, 'B' }, {"fetchsizelimit",required_argument, (int *) 0, LA_FETCHSIZELIMIT }, + {"imapsearchmax",required_argument, (int *) 0, LA_IMAPSEARCHMAX}, {"fastuidl", required_argument, (int *) 0, LA_FASTUIDL }, {"expunge", required_argument, (int *) 0, 'e' }, {"mda", required_argument, (int *) 0, 'm' }, @@ -506,6 +508,10 @@ int parsecmdline (int argc /** argument count */, c = xatoi(optarg, &errflag); ctl->fetchsizelimit = NUM_VALUE_IN(c); break; + case LA_IMAPSEARCHMAX: + c = xatoi(optarg, &errflag); + ctl->imapsearchmax = NUM_VALUE_IN(c); + break; case LA_FASTUIDL: c = xatoi(optarg, &errflag); ctl->fastuidl = NUM_VALUE_IN(c); @@ -687,6 +693,7 @@ int parsecmdline (int argc /** argument count */, P(GT_(" -b, --batchlimit set batch limit for SMTP connections\n")); P(GT_(" -B, --fetchlimit set fetch limit for server connections\n")); P(GT_(" --fetchsizelimit set fetch message size limit\n")); + P(GT_(" --imapsearchmax set max number of imap search messages\n")); P(GT_(" --fastuidl do a binary search for UIDLs\n")); P(GT_(" -e, --expunge set max deletions between expunges\n")); P(GT_(" -m, --mda set MDA to use for forwarding\n")); diff --git a/rcfile_l.l b/rcfile_l.l index c7e49fe..6c80749 100644 --- a/rcfile_l.l +++ b/rcfile_l.l @@ -119,6 +119,7 @@ plugout { return PLUGOUT; } batchlimit { return BATCHLIMIT; } fetchlimit { return FETCHLIMIT; } fetchsizelimit { return FETCHSIZELIMIT; } +imapsearchmax { return IMAPSEARCHMAX; } fastuidl { return FASTUIDL; } expunge { return EXPUNGE; } properties { return PROPERTIES; } diff --git a/rcfile_y.y b/rcfile_y.y index b32a6b0..5ae05f8 100644 --- a/rcfile_y.y +++ b/rcfile_y.y @@ -67,7 +67,7 @@ extern char * yytext; %token SMTPADDRESS SMTPNAME SPAMRESPONSE PRECONNECT POSTCONNECT LIMIT WARNINGS %token INTERFACE MONITOR PLUGIN PLUGOUT %token IS HERE THERE TO MAP -%token BATCHLIMIT FETCHLIMIT FETCHSIZELIMIT FASTUIDL EXPUNGE PROPERTIES +%token BATCHLIMIT FETCHLIMIT FETCHSIZELIMIT IMAPSEARCHMAX FASTUIDL EXPUNGE PROPERTIES %token SET LOGFILE DAEMON SYSLOG IDFILE PIDFILE INVISIBLE POSTMASTER BOUNCEMAIL %token SPAMBOUNCE SOFTBOUNCE SHOWDOTS %token BADHEADER ACCEPT REJECT_ @@ -368,6 +368,7 @@ user_option : TO mapping_list HERE | WARNINGS NUMBER {current.warnings = NUM_VALUE_IN($2);} | FETCHLIMIT NUMBER {current.fetchlimit = NUM_VALUE_IN($2);} | FETCHSIZELIMIT NUMBER {current.fetchsizelimit = NUM_VALUE_IN($2);} + | IMAPSEARCHMAX NUMBER {current.imapsearchmax = NUM_VALUE_IN($2);} | FASTUIDL NUMBER {current.fastuidl = NUM_VALUE_IN($2);} | BATCHLIMIT NUMBER {current.batchlimit = NUM_VALUE_IN($2);} | EXPUNGE NUMBER {current.expunge = NUM_VALUE_IN($2);} -- 1.7.1 |
From: Sunil S. <sun...@ro...> - 2011-04-24 16:37:53
|
Hi Andrea Righi, > To retrieve new messages from a IMAP > folder we use the IMAP SEARCH > command, but we limit the messages processed by the query > to 1000. > This limit is hard-coded and it cannot be changed at > runtime. > > This value is not the best option in some cases, especially > for large > folders, because we need to submit a query each 1000 > messages. > > The following patch introduces a new option (imapsearchmax) > that can be > used to change this limit at runtime. You are missing the point of why there is a limit of 1000 in the IMAP SEARCH command. There is a risk of response truncation when there are more than 1860 new messages in the IMAP folder if the limit is not imposed. To truly test your patch, get a huge mailbox with all new messages(*) and check how many mails get skipped during the first poll. You may even find some mails getting downloaded twice in some edge cases. However, I understand the unnecessary delay in the case when there are very few messages. I will see if there is a better approach than the one currently implemented to avoid the delay as well as proceed in a safer manner. -- Sunil Shetye. (*) Or you may set up a test mailbox, copy existing 10000+ messages to that folder, mark all of them as unread, and test your patch on that folder with the imapsearchmax parameter set to 10000. Note how many messages (including duplicates) get downloaded in one poll of that folder. |
From: Andrea R. <rig...@gm...> - 2011-04-25 15:02:00
|
On Sun, Apr 24, 2011 at 08:07:51PM +0530, Sunil Shetye wrote: > Hi Andrea Righi, > > > To retrieve new messages from a IMAP > > folder we use the IMAP SEARCH > > command, but we limit the messages processed by the query > > to 1000. > > This limit is hard-coded and it cannot be changed at > > runtime. > > > > This value is not the best option in some cases, especially > > for large > > folders, because we need to submit a query each 1000 > > messages. > > > > The following patch introduces a new option (imapsearchmax) > > that can be > > used to change this limit at runtime. > > You are missing the point of why there is a limit of 1000 in the IMAP SEARCH command. There is a risk of response truncation when there are more than 1860 new messages in the IMAP folder if the limit is not imposed. OK, thanks for the clarification, I didn't know about this risk. Maybe a simple and safe improvement could be to check if there are more than 1000 new messages in the folder using a single IMAP SEARCH query and only in this case download the new messages all at once. Otherwise we can fallback to the default behaviour. What do you think? This would be perfect for my case, because even if my IMAP folder is huge, I always have less than 1000 new messages each time fetchmail checks for new messages. > > To truly test your patch, get a huge mailbox with all new messages(*) and check how many mails get skipped during the first poll. You may even find some mails getting downloaded twice in some edge cases. > > However, I understand the unnecessary delay in the case when there are very few messages. I will see if there is a better approach than the one currently implemented to avoid the delay as well as proceed in a safer manner. > > -- > Sunil Shetye. > > (*) Or you may set up a test mailbox, copy existing 10000+ messages to that folder, mark all of them as unread, and test your patch on that folder with the imapsearchmax parameter set to 10000. Note how many messages (including duplicates) get downloaded in one poll of that folder. OK, I'll also prepare a huge mailbox to do some tests and I'll keep you informed. Thanks, -Andrea |
From: Sunil S. <sun...@ro...> - 2011-04-25 22:26:38
|
Hi Andrea, Could you please send your imap server CAPABILITY string? > > You are missing the point of why there is a limit of > 1000 in the IMAP SEARCH command. There is a risk of response > truncation when there are more than 1860 new messages in the > IMAP folder if the limit is not imposed. > > OK, thanks for the clarification, I didn't know about this > risk. > > Maybe a simple and safe improvement could be to check if > there are more > than 1000 new messages in the folder using a single IMAP > SEARCH query > and only in this case download the new messages all at > once. Otherwise > we can fallback to the default behaviour. > > What do you think? Unfortunately, the information as to how many unseen messages are there is coming from the IMAP SEARCH command itself. So, to find out how to run IMAP SEARCH, you need a count of unseen messages and to get that count, you need to run IMAP SEARCH. Quite a chicken-and-egg problem... Is there another way to get the information on the count of unseen messages? There are a few: ================================================================== 1. Parse the response to the SELECT command: A0001 SELECT "INBOX" * EXISTS 10000 * RECENT 1 * OK [UNSEEN 9988] Message 9988 is the first unseen message A0001 OK [READ-WRITE] SELECT COMPLETED (As 9988 is the first unseen message, we know that there are 10000-9988+1=13 or less unseen messages) Status: Required by RFC 3501, Optional in RFC 2060, RFC 1730. Comments: RFC 3501 mentions that if this is missing in the response, client should not make any assumptions and use SEARCH. This means that we are back to square one. 2. Send a STATUS command A0002 STATUS "INBOX" (UNSEEN) * STATUS "INBOX (UNSEEN 13) A0002 OK STATUS COMPLETED Status: Required by RFC 3501, RFC 2060. Not mentioned in RFC 1730. Comments: As it is not supported by all IMAP servers, we cannot rely on this. 3. Send an extended SEARCH command A0003 SEARCH RETURN (COUNT MAX MIN) UNSEEN * ESEARCH (TAG "A0003") MIN 9988 COUNT 13 MAX 10000 A0003 OK SEARCH COMPLETED Status: Supported if CAPABILITY string contains ESEARCH. Mentioned by RFC 4731 in conjunction with RFC 4466. Not mentioned in RFC 3501, RFC 2060, RFC 1730. Comments: As this is an extension, servers supporting this may be rare. ================================================================== As you can see, getting that tiny piece of information in a manner supported by everybody is not going to be easy. As far as possible, fetchmail only uses techniques supported by almost all the imap servers. -- Sunil Shetye. |
From: Andrea R. <rig...@gm...> - 2011-04-26 14:37:02
|
On Tue, Apr 26, 2011 at 01:56:35AM +0530, Sunil Shetye wrote: > Hi Andrea, > > Could you please send your imap server CAPABILITY string? * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN * X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE > > > > You are missing the point of why there is a limit of > > 1000 in the IMAP SEARCH command. There is a risk of response > > truncation when there are more than 1860 new messages in the > > IMAP folder if the limit is not imposed. > > > > OK, thanks for the clarification, I didn't know about this > > risk. > > > > Maybe a simple and safe improvement could be to check if > > there are more > > than 1000 new messages in the folder using a single IMAP > > SEARCH query > > and only in this case download the new messages all at > > once. Otherwise > > we can fallback to the default behaviour. > > > > What do you think? > > Unfortunately, the information as to how many unseen messages are there is coming from the IMAP SEARCH command itself. So, to find out how to run IMAP SEARCH, you need a count of unseen messages and to get that count, you need to run IMAP SEARCH. Quite a chicken-and-egg problem... > > Is there another way to get the information on the count of unseen messages? There are a few: > > ================================================================== > 1. Parse the response to the SELECT command: > > A0001 SELECT "INBOX" > * EXISTS 10000 > * RECENT 1 > * OK [UNSEEN 9988] Message 9988 is the first unseen message > A0001 OK [READ-WRITE] SELECT COMPLETED > > (As 9988 is the first unseen message, we know that there are 10000-9988+1=13 or less unseen messages) > > Status: Required by RFC 3501, Optional in RFC 2060, RFC 1730. > > Comments: RFC 3501 mentions that if this is missing in the response, client should not make any assumptions and use SEARCH. This means that we are back to square one. > > 2. Send a STATUS command > > A0002 STATUS "INBOX" (UNSEEN) > * STATUS "INBOX (UNSEEN 13) > A0002 OK STATUS COMPLETED > > Status: Required by RFC 3501, RFC 2060. Not mentioned in RFC 1730. > > Comments: As it is not supported by all IMAP servers, we cannot rely on this. > > 3. Send an extended SEARCH command > > A0003 SEARCH RETURN (COUNT MAX MIN) UNSEEN > * ESEARCH (TAG "A0003") MIN 9988 COUNT 13 MAX 10000 > A0003 OK SEARCH COMPLETED > > Status: Supported if CAPABILITY string contains ESEARCH. Mentioned by RFC 4731 in conjunction with RFC 4466. Not mentioned in RFC 3501, RFC 2060, RFC 1730. > > Comments: As this is an extension, servers supporting this may be rare. > ================================================================== > > As you can see, getting that tiny piece of information in a manner supported by everybody is not going to be easy. As far as possible, fetchmail only uses techniques supported by almost all the imap servers. I see. :( Any of the solution above should fix my problem, but none of them are generic. Do you think it's too difficult to detect if the server supports one of the method above? In that case we could try to parse the response of these commands and only if we find that at least one works, try to reduce the number of submitted IMAP SEARCH queries. Thanks, -Andrea |
From: Sunil S. <sun...@ro...> - 2011-04-27 07:11:06
|
> > Could you please send your imap server CAPABILITY > string? > > * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID > XLIST CHILDREN > * X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ... > > 1. Parse the response to the SELECT command: Please send from the IMAP logs the output of the SELECT command. You will find something like: IMAP> A0001 SELECT "INBOX" .... IMAP< A0001 OK SELECT completed The whole section is required. Please copy them for two cases: - When there is atleast one new mail in the folder - When there are no new mails in the folder Are you also using IDLE? That could require more IMAP logs from your end around the IDLE command. > > 2. Send a STATUS command The STATUS command might be a bit expensive as it will scan the folder again. There could also be an issue of mismatch between the open folder and the current status of that folder. > > 3. Send an extended SEARCH command This is not supported by your server as it is not advertised in the CAPABILITY string. Implementing this will not help you. > Do you think it's too difficult to detect if the server > supports one of > the method above? In that case we could try to parse the > response of > these commands and only if we find that at least one works, > try to > reduce the number of submitted IMAP SEARCH queries. It would not be difficult. Option 1 and 3 are the most acceptable options as they work on the current folder. It would be easier if we can find what is supported by your server first so that that can be implemented. -- Sunil Shetye. |
From: Andrea R. <rig...@gm...> - 2011-04-29 10:49:03
|
On Wed, Apr 27, 2011 at 10:41:04AM +0530, Sunil Shetye wrote: > > > Could you please send your imap server CAPABILITY > > string? > > > > * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID > > XLIST CHILDREN > > * X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE > > ... > > > > 1. Parse the response to the SELECT command: > > Please send from the IMAP logs the output of the SELECT command. You will find something like: > > IMAP> A0001 SELECT "INBOX" > .... > IMAP< A0001 OK SELECT completed - when there's no new mail: A0001 SELECT "INBOX" * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] * OK [UIDVALIDITY 2] * 518298 EXISTS * 0 RECENT * OK [UIDNEXT 652167] A0001 OK [READ-WRITE] INBOX selected. (Success) - when there's at least one new mail: A0001 SELECT "INBOX" * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] * OK [UIDVALIDITY 2] * 518299 EXISTS * 0 RECENT * OK [UIDNEXT 652168] A0001 OK [READ-WRITE] INBOX selected. (Success) > > The whole section is required. Please copy them for two cases: > > - When there is atleast one new mail in the folder > > - When there are no new mails in the folder > > Are you also using IDLE? That could require more IMAP logs from your end around the IDLE command. No, I don't. > > > > 2. Send a STATUS command > > The STATUS command might be a bit expensive as it will scan the folder again. There could also be an issue of mismatch between the open folder and the current status of that folder. OK. > > > > 3. Send an extended SEARCH command > > This is not supported by your server as it is not advertised in the CAPABILITY string. Implementing this will not help you. OK. Thanks, -Andrea |
From: Matthias A. <mat...@gm...> - 2011-04-30 12:03:39
|
Am 23.04.2011 01:28, schrieb Andrea Righi: > To retrieve new messages from a IMAP folder we use the IMAP SEARCH > command, but we limit the messages processed by the query to 1000. > This limit is hard-coded and it cannot be changed at runtime. > > This value is not the best option in some cases, especially for large > folders, because we need to submit a query each 1000 messages. > > The following patch introduces a new option (imapsearchmax) that can be > used to change this limit at runtime. I wonder how much of that would survive the planned UID use in IMAP. :) |
From: Matthias A. <mat...@gm...> - 2011-05-01 09:33:43
|
Am 23.04.2011 01:28, schrieb Andrea Righi: > To retrieve new messages from a IMAP folder we use the IMAP SEARCH > command, but we limit the messages processed by the query to 1000. > This limit is hard-coded and it cannot be changed at runtime. > > This value is not the best option in some cases, especially for large > folders, because we need to submit a query each 1000 messages. > > The following patch introduces a new option (imapsearchmax) that can be > used to change this limit at runtime. Note that Exchange 2010 may also need a server-side fix then. If we're not up in the 2000+ range we apparently don't trigger it: http://support.microsoft.com/kb/2494798/en-us |