fetchmail-devel — Development related discussion

Re: [fetchmail-devel] timeout not working for TLS

[Thomas J. <tho...@in...>]

Hello Matthias,

On Thursday, 5. August 2010 00:18:30 Matthias Andree wrote:
> The attached patch sets the timeout for the getauth() stage (which
> entails STARTTLS-like negotiation). Please try that too and see if you
> get timeout reports while fetchmail tries to negotiate TLS. It should.
> 
> Thanks for the report and offered help in debugging. Would be good if you
> could report back in a month or so :-)

I just had another case of this issue on a different box,
this time running fetchmail 6.3.18.

Here's all the info I was able to collect:

Log from fetchmail:
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< TOP
fetchmail: POP3< USER
fetchmail: POP3< UIDL
fetchmail: POP3< STLS
fetchmail: POP3< SASL PLAIN
fetchmail: POP3< IMPLEMENTATION trinity
fetchmail: POP3< .
fetchmail: POP3> STLS
fetchmail: POP3< +OK Begin TLS negotiation

fetchmail was stuck at that line since 21.04.2011.

[root@intranator log]# strace -p 1505
Process 1505 attached - interrupt to quit
read(3,

(gdb) bt
#0  0x00c17424 in __kernel_vsyscall ()
#1  0x00867ef3 in __read_nocancel () at ../sysdeps/unix/syscall-
template.S:82
#2  0x0033771e in sock_read () from /usr/lib/libcrypto.so.8
#3  0x00000003 in ?? ()
#4  0x09e7cafe in ?? ()
#5  0x000006bf in ?? ()
#6  0x89f4e239 in ?? ()
#7  0x6ce90be1 in ?? ()
#8  0xa8a2f11c in ?? ()
#9  0x60917bce in ?? ()
#10 0x003c8c28 in ?? () from /usr/lib/libcrypto.so.8
#11 0x09e762f8 in ?? ()
#12 0x00000000 in ?? ()


Even though I installed the -debuginfo packages,
I wasn't able to get a meaningful backtrace.

So the stall happens before the authentication state?

Cheers,
Thomas

Re: [fetchmail-devel] imap: introduce imapsearchmax parameter

[Sunil S. <sun...@ro...>]

> > 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.

Re: [fetchmail-devel] imap: introduce imapsearchmax parameter

[Andrea R. <rig...@gm...>]

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

Re: [fetchmail-devel] imap: introduce imapsearchmax parameter

[Sunil S. <sun...@ro...>]

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.

Re: [fetchmail-devel] imap: introduce imapsearchmax parameter

[Andrea R. <rig...@gm...>]

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

Re: [fetchmail-devel] imap: introduce imapsearchmax parameter

[Sunil S. <sun...@ro...>]

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.

[fetchmail-devel] [PATCH] imap: introduce imapsearchmax parameter

[Andrea R. <rig...@gm...>]

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

[fetchmail-devel] [Patch #740] adds IMAP UID support, lacks UIDVALIDITY

[<ad...@be...>]

Patch #740 has been updated. 

Project: fetchmail
Category: None
Status: Rejected
Submitted by: m-a
Assigned to : m-a
Summary: adds IMAP UID support, lacks UIDVALIDITY

Follow-Ups:

Date: 2011-Mar-30 10:23
By: m-a

Comment:
Also note that the patch doesn't use the mandatory IMAP UID commands, but cooks its own version that is very data intensive and thus inefficient.  I think I'll go for a different approach.
-------------------------------------------------------

Date: 2007-Jun-04 17:40
By: m-a

Comment:
Yes, it's desirable and planned for the next major release (not 6.3.X), but UIDVALIDITY is a requirement.
-------------------------------------------------------

Date: 2007-Jun-04 17:36
By: mfrasca

Comment:
this is for me a very desirable feature...  it would make it possible to use the same IMAP account from different computers.  I saw this works, why not include it in the main sources?

I had planned to do something similar, but then more simply based on the timestamp of the last synchronization. it would be quicker, but at the moment it's just an idea.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://developer.berlios.de/patch/?func=detailpatch&patch_id=740&group_id=1824

[fetchmail-devel] New Chinese (simplified) PO file for 'fetchmail' (version 6.3.19-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Chinese (simplified) team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/zh_CN.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] [Patch #3116] Allow selection of LAST envelope header

[<ad...@be...>]

Patch #3116 has been updated. 

Project: fetchmail
Category: None
Status: Open
Submitted by: mskala
Assigned to : none
Summary: Allow selection of LAST envelope header

Follow-Ups:

Date: 2011-Jan-08 20:29
By: mskala

Comment:
My ISP unconditionally adds an X-Envelope-To: header at the end of the message header block.  Sometimes a message comes in which already has an X-Envelope-To: header, generally with an address my sendmail will think is non-local and reject; messages that come through the XeTeX development mailing list often fit this description, because for whatever reason they arrive containing their own X-Envelope-To: headers pointing at the list instead of at me.

If I just tell Fetchmail to use X-Envelope-To:, it reads the first one, which is the one added by my ISP in most cases but the one that came in with the message for the few messages that already have them.  When the message comes with an X-Envelope-To header and Fetchmail reads it, it can't deliver the message properly.  Fetchmail would allow me to skip a constant number of headers - so I could tell it to skip 1 and then it would always read the second X-Envelope-To: header - but in that case it would fail on the large majority of messages where my ISP's header is the only one.  What I would really like would be to read the LAST X-Envelope-To: header, regardless of how many (if any) must be skipped to do that.

This patch (against fetchmail-6.3.19) accomplishes that.  If I set the "skip" value to -1, then Fetchmail will use the LAST envelope header, which (in my case) is always the one added by my ISP.  For values of skip other than -1, it preserves the old behaviour.  Since -1 was formerly an invalid setting for skip (though not tested for), it shouldn't disturb existing correct behaviour.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://developer.berlios.de/patch/?func=detailpatch&patch_id=3116&group_id=1824

[fetchmail-devel] [Patch #3116] Allow selection of LAST envelope header

[<ad...@be...>]

Patch #3116 has been updated. 

Project: fetchmail
Category: None
Status: Open
Submitted by: mskala
Assigned to : none
Summary: Allow selection of LAST envelope header

-------------------------------------------------------
For more info, visit:

http://developer.berlios.de/patch/?func=detailpatch&patch_id=3116&group_id=1824

Re: [fetchmail-devel] Presently running code

[Rainer W. <rwe...@ms...>]

Matthias Andree <mat...@gm...> writes:
> Am 12.06.2010 00:06, schrieb Rainer Weikusat:
>> "Matthias Andree" <mat...@gm...> writes:
>> 
>>> Am 08.06.2010, 23:57 Uhr, schrieb Rainer Weikusat:
>>>
>>>> The file included below is a diff of the 'running' uid_db code against
>>>> the 6.3.17 fetchmail tree. I hope that it is ok in this form, because
>>>> I'm still in extreme 'now, we just need to deliver'-mode ...
>> 
>> [...]
>> 
>>> Is that the final submission to be expected, or do you still want to
>>> polish some bits of it?
>> 
>> This is the code which is used for the POP3-using customers of 'my'
>> application. Because of this, I will fix or mitigate any issues with
>> it which come to my attention and affect me. As always, I'm meanwhile
>> working on something completely different with the usual 'Yesterday!'
>> [emphatically!] as most wanted release date. This means the short
>> answer is 'Yes' and the medium-sized one would be "I can want things
>> all day but that doesn't mean I can actually do them :-(".
>
> Hi Rainer,
>
> thanks again for the contribution.  I have finally rebased your patch onto
> 6.3.19, and then merged it for 6.4.0-alpha1 (in Git's next branch, see
> http://gitorious.org/fetchmail/ for the repositories).
>
> I'd like you to look over the changes; specifically I had to initialize "v" in
> two functions to 0 explicitly to fix compiler warnings.
>
> I'd also appreciate if you could read the code and check for merge errors.

I apologize for the delayed reply, I've moved to the UK last Friday
(2010/12/10) and I'm still in the process of forcing the resulting
chaos out of my life again. I'll be busy with catching up on
work I had leave on its own since then but I'll try to have a look at
this in the next few days.

[fetchmail-devel] fetchmail 7.0.0-alpha1 alpha preview release

[Matthias A. <mat...@gm...>]

Greetings,

in an effort to get sufficient testing, I have released the first alpha
version of fetchmail 7.0.0.

The alpha version isn't available through BerliOS, but only from
DOWNLOAD: <http://home.pages.de/~mandree/fetchmail/>

The corresponding git tag is SNAPSHOT_7-0-0-alpha1, the branch is
"next".

Please send feedback to fet...@li....

Happy fetching!
Matthias

--------------------------------------------------------------------------------

fetchmail-7.0.0 (not yet released):

NOTE THIS IS AN ALPHA RELEASE THAT HAS NOT BEEN THOROUGHLY TESTED!

# MAJOR CHANGES
* The UIDL handler code is now much faster, especially noticable with lots of
  mail kept on a POP3 server. Where the 6.3.X code was of O(n^2) complexity,
  we're down to O(n log n).
  Contributed by Rainer Weikusat, MAD Partners Ltd./MSS GmbH.
* The POP3 code now always uses UIDL, except if "fetchall" is in effect.
  Fixes BerliOS Bug #16172.

# FEATURES ADDED
* Fetchmail can now retrieve credentials from PWMD. This needs to be enabled at
  compile-time and requires run-time configuration. See README.PWMD for details.
  Contributed by Ben Kibbey, author of libpwmd and pwmd.
* Fetchmail now supports a retrieve-error command line or rcfile option that
  takes exactly one argument, abort (default), continue or markseen.  This
  specifies the policy used by fetchmail to handle messages whose bodies
  fail to be retrieved due to server errors.  Both the continue and markseen
  options will skip the message with errors and allow the session to
  continue so that subsequent messages can be retrieved.  The markseen
  option will also mark the message with errors as seen.
  The default policy is to abort the session whenever a server error occurs.
  Contributed by Craig Brown.

# REMOVED FEATURES
* POP2 was removed
* RPOP (not actually a protocol, but a variant of POP3) was removed
* POP3: the uidl option has been removed. It is no longer configurable.
* POP3: LAST is no longer used. It was removed from POP3 in 1994, and it could
  cause mail loss.
* Trio was removed, fetchmail expects reasonable stdio.h support levels.
* Support for systems that do not conform to C89 and POSIX 2001 was removed,
  this means that BeOS, EMX, NeXTSTEP quirks are no longer worked around.
* The MX and host alias DNS lookups that fetchmail performs in multidrop mode
  have been removed. They were based on the mistaken assumption that the
  IMAP/POP3 server was also the MX server, which is rarely the case.  They have
  never supported IPv6 (including IPv6-mapped IPv4) either.
  Non-DNS based alias keywords such as "aka" remain.
* Kerberos IV support was removed.

# CHANGES
* fetchmail now always uses its own MD5 implementation.  The library and header
  variants are too diverse, and we've been bitten before -- and configure
  complains noisily on Cyrus-SASL's RFC1321 md5.h.

[fetchmail-devel] [Patch #1588] credentials file patch

[<ad...@be...>]

Patch #1588 has been updated. 

Project: fetchmail
Category: None
Status: Closed
Submitted by: bjk
Assigned to : none
Summary: credentials file patch

Follow-Ups:

Date: 2010-Dec-14 13:05
By: m-a

Comment:
Rejected per submitters's assertion that it is obsoleted by PWMD.
-------------------------------------------------------

Date: 2008-Sep-26 01:14
By: bjk

Comment:
I was using the Exim MTA password file as shared credentials with fetchmail. This isn't needed anymore if PWMD is used.
-------------------------------------------------------

Date: 2008-Sep-24 21:05
By: m-a

Comment:
why is this needed at all given we have netrc support?
-------------------------------------------------------

Date: 2006-Nov-12 23:30
By: m-a

Comment:
shelved for fetchmail 6.4
-------------------------------------------------------

Date: 2006-Oct-28 20:21
By: bjk

Comment:
Adds a command-line and rcfile parameter "credentials" which is a filename containing lines like: hostname:username:password. Matching is taking from the server parameters. I'm not to experienced with lexers but it seems to work.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://developer.berlios.de/patch/?func=detailpatch&patch_id=1588&group_id=1824

[fetchmail-devel] [Patch #1859] PWMD support

[<ad...@be...>]

Patch #1859 has been updated. 

Project: fetchmail
Category: None
Status: Closed
Submitted by: bjk
Assigned to : m-a
Summary: PWMD support

Follow-Ups:

Date: 2010-Dec-14 13:04
By: m-a

Comment:
The corresponding Gitorious merge request was accepted and merged into 'next' branch in Git (to be pushed to Gitorious once it's back up).

-------------------------------------------------------

Date: 2010-Feb-11 02:44
By: m-a

Comment:
Hi Ben,

thanks for keeping this feature up to date.

I've recently migrated the source code management to Git and it's hosted on http://gitorious.org/fetchmail/ (free of charge) - that site allows easy cloning and merging for such contributions, so it may be worth a spin.

I'd also be interested to merge, but we're a while back from that state where I'll have revived the 7.0 development branch sufficiently that it's worth doing.

Matthias

-------------------------------------------------------

Date: 2010-Feb-11 01:18
By: bjk

Comment:
Minor fix to patch against fetchmail 6.3.14.
-------------------------------------------------------

Date: 2010-Jan-13 23:11
By: bjk

Comment:
This new version fixes reconnecting to the same socket specified in the rcfile. Useful if there is more than one account specified which uses the same pwmd socket.
-------------------------------------------------------

Date: 2009-Apr-30 02:10
By: bjk

Comment:
Updated to use libpwmd6.
-------------------------------------------------------

Date: 2008-Oct-19 19:10
By: bjk

Comment:
Really use the pwmd pinentry method.
-------------------------------------------------------

Date: 2008-Jul-11 19:23
By: bjk

Comment:
Now uses pwmds (v1.11) pinentry method for pinentry timeouts.
-------------------------------------------------------

Date: 2008-Jan-26 20:09
By: bjk

Comment:
Another fix for lock file checking.
-------------------------------------------------------

Date: 2008-Jan-12 21:37
By: bjk

Comment:
This re-adds pinentry timeout support and fixes the previous patch complaining about an existing fetchmail running.
-------------------------------------------------------

Date: 2008-Jan-06 19:05
By: bjk

Comment:
Updated to work with libpwmd5. This revision removes pinentry timeouts so make sure the password is cached on the server when running in daemon mode otherwise if your away pinentry will block the fetchmail daemon waiting for input. It also checks the pwmd server at each poll interval.
-------------------------------------------------------

Date: 2007-Oct-20 19:53
By: bjk

Comment:
Here's a new patch for fetchmail 6.3.8 and libpwmd4. Includes pinentry settings. I'm not sure how to handle timeouts and errors connecting to pwmd. As it is now it'll exit like fetchmail does when it encounters an rcfile parse error.
-------------------------------------------------------

Date: 2007-Feb-17 17:47
By: bjk

Comment:
Password Manager Daemon. It servers clients data whch is stored in an encrypted XML file. A client connects, provides a password to open a file and issues protocol commands to manipulate the data. It's a work in progress.

The fetchmail patch uses PWMD to get server info (hostname, sslfingerprint, port, etc), username and password info.
-------------------------------------------------------

Date: 2007-Feb-16 23:42
By: m-a

Comment:
What's PWMD?
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://developer.berlios.de/patch/?func=detailpatch&patch_id=1859&group_id=1824

Re: [fetchmail-devel] Presently running code

[Matthias A. <mat...@gm...>]

Am 12.06.2010 00:06, schrieb Rainer Weikusat:
> "Matthias Andree" <mat...@gm...> writes:
> 
>> Am 08.06.2010, 23:57 Uhr, schrieb Rainer Weikusat:
>>
>>> The file included below is a diff of the 'running' uid_db code against
>>> the 6.3.17 fetchmail tree. I hope that it is ok in this form, because
>>> I'm still in extreme 'now, we just need to deliver'-mode ...
> 
> [...]
> 
>> Is that the final submission to be expected, or do you still want to
>> polish some bits of it?
> 
> This is the code which is used for the POP3-using customers of 'my'
> application. Because of this, I will fix or mitigate any issues with
> it which come to my attention and affect me. As always, I'm meanwhile
> working on something completely different with the usual 'Yesterday!'
> [emphatically!] as most wanted release date. This means the short
> answer is 'Yes' and the medium-sized one would be "I can want things
> all day but that doesn't mean I can actually do them :-(".

Hi Rainer,

thanks again for the contribution.  I have finally rebased your patch onto
6.3.19, and then merged it for 6.4.0-alpha1 (in Git's next branch, see
http://gitorious.org/fetchmail/ for the repositories).

I'd like you to look over the changes; specifically I had to initialize "v" in
two functions to 0 explicitly to fix compiler warnings.

I'd also appreciate if you could read the code and check for merge errors.

Thanks again.

Best regards

-- 
Matthias Andree

[fetchmail-devel] New Japanese PO file for 'fetchmail' (version 6.3.19-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Japanese team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/ja.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] [Bug #16172] Fetchmail eats mail when unable to connect to SMTP

[<ad...@be...>]

Bug #16172, was updated on 2009-Aug-24 10:38
Here is a current snapshot of the bug.

Project: fetchmail
Category: None
Status: Closed
Resolution: Invalid
Bug Group: None
Priority: 7
Submitted by: bennovdbogaard
Assigned to : m-a
Summary: Fetchmail eats mail when unable to connect to SMTP

Details: Hello everyone,

I use fetchmail in various production environments and I discovered some unwanted behaviour.

After fetchmail fetches mail from a pop mail server it removes messages after they are retrieved. But if the SMTP to deliver these messages to isn't available, it drops the messages and gives up instantly.

Could this behaviour be altered by first checking if the SMTP server is reachable and then decide to fetch the messages?

Yours,
Benno van den Bogaard <be...@ho...>

Follow-Ups:

Date: 2010-Dec-10 20:44
By: m-a

Comment:
There is insufficient information in the bug report, closing as invalid. Be sure to use --uidl for POP3 retrieval.
-------------------------------------------------------

Date: 2010-Apr-09 09:51
By: m-a

Comment:
Benno,

can I _please_ get a verbose trace showing the message loss? Thank you.
-------------------------------------------------------

Date: 2009-Aug-24 14:05
By: m-a

Comment:
Please prove through complete logs that fetchmail 6.3.10 or 6.3.11 loses mail and to show it's not a server fault (some servers are known to delete mail after retrieval even if the client hasn't requested deletion; also, some may make deletes effective before QUIT).

See http://www.fetchmail.info/fetchmail-FAQ.html#G3 for a list of pieces of information that we need to debug the issue.

Fetchmail has been designed to NOT delete messages from the server before it has successfully delivered them.

-------------------------------------------------------

For detailed info, follow this link:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=16172&group_id=1824

[fetchmail-devel] [Bug #17599] antispam does not work

[<ad...@be...>]

Bug #17599, was updated on 2010-Oct-13 11:03
Here is a current snapshot of the bug.

Project: fetchmail
Category: None
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: keesbakker
Assigned to : shetye
Summary: antispam does not work

Details: The --antispam option does not work (anymore?). I guess, it must have been disfunctional since 2002-sep-04, when a patch from Sunil Shetye ("double-bounce patch") was applied. (Git commit efe3c6cc82e214142809c77c4f2fa8a58bdef787)

The code that was added in sink.c has this piece

   if (str_find(&ctl->antispam, smtperr))

And the problem is that the function returns a NULL pointer even if it finds the requested value.

Notice that there is another location in sink.c which searches the ctl->antispam list using a while loop.


Follow-Ups:

Date: 2010-Dec-10 20:30
By: m-a

Comment:
should be fixed in 6.3.19
-------------------------------------------------------

Date: 2010-Oct-21 13:26
By: m-a

Comment:
Hi Kees,

thanks for the report.  I have pushed Sunil's patch to the Git repository.  Could you please let us know if that fixes your problem?

Best regards
Matthias
-------------------------------------------------------

For detailed info, follow this link:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=17599&group_id=1824

[fetchmail-devel] fetchmail 6.3.19 regression/bug fix release

[Matthias A. <mat...@gm...>]

The 6.3.19 release of fetchmail is now available at the usual locations,
including <http://developer.berlios.de/projects/fetchmail>.

The source archive is available at:
<http://developer.berlios.de/projects/fetchmail/fetchmail-6.3.19.tar.bz2>

Here are the release notes:

fetchmail-6.3.19 (released 2010-12-10, 25945 LoC):

# ERRATUM NOTICE ISSUED
* fetchmail 6.3.18 contains several bug fixes that were considered sufficiently
  grave to warrant the issue of an erratum notice, fetchmail-EN-2010-03.txt.

# BUG FIXES
* When specifying multiple local multidrop lists, do not lose wildcard flag.
  (Affects "user foo is bar baz * is joe here")
* In multidrop configurations, an asterisk can now appear anywhere in the list
  of local users, not just at the end.
* In multidrop mode, header parsing is now more verbose in -vv mode, so that it
  becomes possible to see which header is used.
* Make --antispam work from command line (these used to work in rcfiles).
  Reported by Kees Bakker, BerliOS Bug #17599. (Sunil Shetye)
* Smoke test XHTML 1.1 validation, and if it fails, skip validating HTML
  documents.  Skip validating Mailbox-Names-UTF7.html. Several systems have
  broken XHTML 1.1 DTD installations that jeopardize the build.
  Reported by Mihail Nechkin against FreeBSD port.
  Workaround for 6.3.18: build in a separate directory, i. e:
  mkdir build && cd build && ../configure --options-go-here
* Send a NOOP only after a failed STARTTLS in IMAP. (Sunil Shetye)
* Demote GSSAPI verbose/debug syslog to INFO severity. Requested by Carlos E. R.
  and Derek Simkowiak via the fetchmail-users@ mailing list.
* Do STARTTLS/STLS negotiation in IMAP/POP3 if it is mandatory even if the
  server capabilities do not show support for upgradation to TLS.
  To use this, configure --sslproto tls1. (Sunil Shetye)
* IMAP: Understand empty strings as FETCH response, seen on Yahoo. Reported by
  Yasin Malli to fetchmail-users@ 2010-12-10.
  Note that fetchmail continues to expect literals as FETCH response for now.

# DOCUMENTATION
* The manual page now links to IANA for GSSAPI service names.

# TRANSLATION UPDATES
  [cs]    Czech (Petr Pisar)
  [fr]    French (Frédéric Marchal)
  [de]    German
  [it]    Italian (Vincenzo Campanella)
  [pl]    Polish (Jakub Bogusz)

# KNOWN BUGS AND WORKAROUNDS
  (this section floats upwards through the NEWS file so it stays with the
  current release information - however, it was stuck with 6.3.8 for a while)
* fetchmail does not handle messages without Message-ID header well
  (See sourceforge.net bug #780933)
* BSMTP is mostly untested and errors can cause corrupt output.
* Sun Workshop 6 (SPARC) is known to miscompile the configuration file lexer in
  64-bit mode.  Either compile 32-bit code or use GCC to compile 64-bit
  fetchmail.  Note that fetchmail doesn't take advantage of 64-bit code,
  so compiling 32-bit SPARC code should not cause any difficulties.
* fetchmail does not track pending deletes over crashes.
* the command line interface is sometimes a bit stubborn, for instance,
  fetchmail -s doesn't work with a daemon running.
* Linux systems may return duplicates of an IP address in some circumstances if
  no or no global IPv6 addresses are configured.
  (No workaround. Ubuntu Bug#582585, Novell Bug#606980.)
* Kerberos 5 may be broken, particularly on Heimdal, and provide bogus error
  messages. This will not be fixed, because the maintainer has no Kerberos 5
  server to test against. Use GSSAPI.


By popular demand, diffs from the previous release have been omitted.

[fetchmail-devel] New Czech PO file for 'fetchmail' (version 6.3.19-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Czech team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/cs.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New Italian PO file for 'fetchmail' (version 6.3.19-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Italian team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/it.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New Polish PO file for 'fetchmail' (version 6.3.19-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Polish team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/pl.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New French PO file for 'fetchmail' (version 6.3.19-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the French team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/fr.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New template for 'fetchmail' made available

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to <coo...@tr...>.)

A new POT file for textual domain 'fetchmail' has been made available
to the language teams for translation.  It is archived as:

    http://translationproject.org/POT-files/fetchmail-6.3.19-pre1.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

    http://www.dt.e-technik.tu-dortmund.de/~ma/fetchmail/fetchmail-6.3.19-pre1.tar.bz2

We can arrange things so that translated PO files are automatically e-mailed
to you when they arrive.  Ask at the address below if you want this.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>