fetchmail-devel — Development related discussion

Re: [fetchmail-devel] [PATCH] potential memory and socket leak fix

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

Sunil Shetye <sh...@bo...> writes:

> This minor patch fixes potential memory and socket leak. The memory
> leak can occur when multiple folders are being polled.

Merged, thank you.

-- 
Matthias Andree

[fetchmail-devel] [PATCH] potential memory and socket leak fix

[Sunil S. <sh...@bo...>]

Hi,

This minor patch fixes potential memory and socket leak. The memory
leak can occur when multiple folders are being polled.

====================================================================================
Index: fetchmail/driver.c
===================================================================
--- fetchmail/driver.c	(revision 4523)
+++ fetchmail/driver.c	(working copy)
@@ -1373,7 +1373,8 @@
 		    if (count > INT_MAX/sizeof(int))
 		    {
 			report(stderr, GT_("bogus message count!"));
-			return(PS_PROTOCOL);
+			err = PS_PROTOCOL;
+			goto cleanUp;
 		    }
 
 		    /* 
@@ -1389,6 +1390,7 @@
 		    if (proto->getsizes &&
 			!(proto->getpartialsizes && NUM_NONZERO(ctl->fetchsizelimit)))
 		    {
+			xfree(msgsizes);
 			msgsizes = xmalloc(sizeof(int) * count);
 			for (i = 0; i < count; i++)
 			    msgsizes[i] = 0;
====================================================================================

-- 
Sunil Shetye.

Re: [fetchmail-devel] [PATCH] imap rfc issues

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

Sunil Shetye <sh...@bo...> writes:

> The code in imap.c incorrectly indicates that "STORE ... +FLAGS.SILENT"
> has been removed in IMAP4rev1. RFCs 3501 and 2060 clearly state that
> this is supported. This patch uses FLAGS.SILENT for IMAP4rev1 too.

Good catch, thanks a lot. I'm inclined NOT to merge this into 6.3.X
though as it's not strictly a fix, and I fear we might destabilize
fetchmail. I'll take the complete patch for 6.4.0 though and merge on
the SVN trunk.

The nice set of test sites ESR used to have has melted down to five
sites, which is next to useless. We need to raise test sites again...

Given that all the IMAP world talks IMAP4rev1 now, we'd effectively
change default behavior and may run into server bugs we haven't seen
yet, I'll just take:

> Also, fetchmailconf warns of BODY[TEXT] with Netscape IMAP4rev1.
> However, since fetchmail uses BODY.PEEK[TEXT] with an IMAP4rev1
> server, the warning is not required.

...this part for 6.3.1.

> Also, RFC 2060 is obsoleted by RFC 3501.

I know, but haven't reviewed the IMAP code for the clarifications, so
I'd say we'll leave "2060" in 6.3.X, too.

Is there anything that changed between 2060 and 3501 that might affect
fetchmail? If so, I'd appreciate an incremental patch against the SVN
trunk.

-- 
Matthias Andree

[fetchmail-devel] [PATCH] imap rfc issues

[Sunil S. <sh...@bo...>]

Hi,

The code in imap.c incorrectly indicates that "STORE ... +FLAGS.SILENT"
has been removed in IMAP4rev1. RFCs 3501 and 2060 clearly state that
this is supported. This patch uses FLAGS.SILENT for IMAP4rev1 too.

Also, fetchmailconf warns of BODY[TEXT] with Netscape IMAP4rev1.
However, since fetchmail uses BODY.PEEK[TEXT] with an IMAP4rev1
server, the warning is not required.

Also, RFC 2060 is obsoleted by RFC 3501.

This patch fixes all these issues.

-- 
Sunil Shetye.

Re: [fetchmail-devel] Re: 6.3.0 is out - SVN overview

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

Sunil Shetye <sh...@bo...> writes:

> fetchmail 6.3.0 seems to have been built with gettext 0.14 and not
> 0.14.3. Is that deliberate?

No, I was unaware of this, and the gettext toolchain or cvs must have
failed at some point in time, copying 0.14.3 files there - there should
never have been anything except 0.10.stoneage, 0.13 or 0.14.1 in the
tarball. I'll be shipping 0.14.3 files with fetchmail 6.3.1.

> fetchmail 6.2.9-rc10 was built with gettext 0.14.3.

Yup. And this was an accident somehow. According to configure.ac, 0.14.1
should have been used.

-- 
Matthias Andree

[fetchmail-devel] Re: fetchmail segfault on 'empty' mail

[Daniel D. <ds...@ge...>]

Hi Sunil,

Sunil Shetye wrote:
> Please send the output of "fetchmail -v" before and after the patch
> when you have an empty mail in your mailbox. This will show that the
> patch indeed works correctly and only that empty mail is getting
> properly deleted when you have multiple mails in your mailbox.

I don't have any more of these mails right now, so this is fairly fabricated, 
but more or less accurate.

Before:

fetchmail: 6.2.5.2 querying aap.businessserve.co.uk (protocol POP3) at Wed, 07 
Dec 2005 13:20:02 +0000 (GMT): poll started
fetchmail: POP3< +OK <..>
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR authorization first
fetchmail: authorization first
fetchmail: Repoll immediately on xxx
fetchmail: POP3< +OK <..>
fetchmail: POP3> USER xxx
fetchmail: POP3< +OK
fetchmail: POP3> PASS *
fetchmail: POP3< +OK
fetchmail: POP3> STAT
fetchmail: POP3< +OK 26 82969
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 1329
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK 1329 octets follow.
reading message xyz:1 of 26 (1329 octets)
Segmentation fault

After:

fetchmail: 6.2.5.2 querying aap.businessserve.co.uk (protocol POP3) at Wed, 07 
Dec 2005 13:20:02 +0000 (GMT): poll started
fetchmail: POP3< +OK <..>
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR authorization first
fetchmail: authorization first
fetchmail: Repoll immediately on xxx
fetchmail: POP3< +OK <..>
fetchmail: POP3> USER xxx
fetchmail: POP3< +OK
fetchmail: POP3> PASS *
fetchmail: POP3< +OK
fetchmail: POP3> STAT
fetchmail: POP3< +OK 26 82969
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 1329
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK 1329 octets follow.
reading message xyz:1 of 26 (1329 octets)
***** message delimiter found while scanning headers
flushed
fetchmail: POP3> LIST 2
...

> Do you keep on getting such empty mails frequently? Or, did that
> happen only once?

This system has been running fetchmail for about a year, and this is the first 
time I have seen this. 5 of these mails were received in a short space of time.

Daniel

[fetchmail-devel] Re: 6.3.0 is out - SVN overview

[Sunil S. <sh...@bo...>]

Quoting from Matthias Andree's mail on Thu, Dec 01, 2005:
> 2. I have tagged r4499 as
>    https://decoy.wox.org/svn/fetchmail/tags/RELEASE_6-3-0 - running
>    "make dist" on this branch should reproduce the release tarball with
>    reasonable accuracy. I've used automake 1.9.6, autoconf 2.59, gettext
>    0.14.3, flex 2.5.4 and bison 1.875 to build.

fetchmail 6.3.0 seems to have been built with gettext 0.14 and not
0.14.3. Is that deliberate?

fetchmail 6.2.9-rc10 was built with gettext 0.14.3.

-- 
Sunil Shetye.

[fetchmail-devel] Re: fetchmail segfault on 'empty' mail

[Sunil S. <sh...@bo...>]

Quoting from Daniel Drake's mail on Tue, Dec 06, 2005:
> I don't know what the upstream server runs. Is there a way of figuring this 
> out through the server? It is an ISP POP3 server running at 
> aap.businessserve.co.uk
> 
> I am running Gentoo Linux which compiles fetchmail from source, however I 
> also reproduced the bug on an unmodified locally compiled fetchmail-6.3.0
> 
> My .fetchmailrc :
> 
> poll aap.businessserve.co.uk proto pop3 no dns localdomains mydomain.com:
> envelope "Delivered-To:"
> user xxx with pass xxx to * here keep

Please send the output of "fetchmail -v" before and after the patch
when you have an empty mail in your mailbox. This will show that the
patch indeed works correctly and only that empty mail is getting
properly deleted when you have multiple mails in your mailbox.

Do you keep on getting such empty mails frequently? Or, did that
happen only once?

-- 
Sunil Shetye.

[fetchmail-devel] Fetchmail 6.3.0 released

[Rob F. <rf...@fu...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The Community Fetchmail team is happy to announce the release of
Fetchmail 6.3.0 on 30 November, 2005.

More than two years after the previous formal 6.2.5 release, this
collects several dozen bug fixes, documentation, portability and IPv6
improvements and marks the beginning of a new "stable" 6.3.X branch
that will not change, except for bug fixes and documentation updates.

This is also the first major release from the new Community Fetchmail
maintenance team, which took over from longtime maintainer Eric S.
Raymond in June 2004.  As a result of this change, the Fetchmail
home page moved to:
  http://fetchmail.berlios.de/
And the mailing list focus has moved to the lists hosted at Berlios,
located at:
  http://developer.berlios.de/mail/?group_id=1824

Future versions of Fetchmail with new features or changes that affect
Fetchmail's behavior will be called 6.4.0 or 7.0.0 depending how large
the impact is.  This means that we will not have "gold" releases any
more, but instead the 6.3.X release with the greatest X is usually the
best.

Changes between Fetchmail 6.2.5 and 6.3.0:
The --netsec/-T options were removed. The --smtphost is now always
"localhost". fetchmail now uses automake. Internationalization now
requires gettext 0.14 to be installed separately. More than 140
user-visible changes were made, most of them bugfixes. Some
documentation and translation updates were made to improve stability
and protocol conformance, to improve bounce and warning messages, and
to improve portability.

(Note: for those who downloaded the .asc GnuPG signature file in the
first 23 hours after release, they will have seen "BAD signature". The
signature file was broken by the maintainer's last-minute change to
the NEWS file. A new signature file was uploaded on 2005-12-01 at
23:57 UTC.)


About Fetchmail:
Fetchmail is a free, full-featured, robust, well-documented
remote-mail retrieval and forwarding utility intended to be used over
on-demand TCP/IP links (such as SLIP or PPP connections). It supports
every remote-mail protocol now in use on the Internet: POP2, POP3,
RPOP, APOP, KPOP, all flavors of IMAP, and ESMTP ETRN. It can even
support IPv6 and IPSEC.

http://fetchmail.berlios.de/

- -- 
==============================| "A slice of life isn't the whole cake
 Rob Funk <rf...@fu...> | One tooth will never make a full grin"
 http://www.funknet.net/rfunk |    -- Chris Mars, "Stuck in Rewind"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDlllNC+BU/gUoZAMRArMYAJ0ahklzCKWTMQpPjOLBEO9axKWROgCfZfre
QOHK0M3WNJcLymdpQnw6mPw=
=eZUA
-----END PGP SIGNATURE-----

[fetchmail-devel] Re: [fetchmail]Re: fetchmail segfault on 'empty' mail

[Daniel D. <ds...@ge...>]

Matthias Andree wrote:
> On Mon, 05 Dec 2005, Daniel Drake wrote:
> 
> 
>>Hi,
>>
>>I noticed that my fetchmail was segfaulting at the very start of a 
>>particular mail message, with this trace:
>>
>>#0  0xb7e67423 in strlen () from /lib/tls/libc.so.6
>>#1  0x0805cded in readheaders (sock=6, fetchlen=0, reallen=0, 
>>ctl=0x808d2d8, num=2, suppress_readbody=0xbff7c835 "")
>>    at transact.c:920
>>#2  0x080597df in fetch_messages (mailserver_socket=6, ctl=0x808d2d8, 
>>count=272, msgsizes=0xbff7c7f0, maxfetch=0,
>>    fetches=0xbff7e8c0, dispatches=0xbff7e8bc, deletions=0xbff7e8cc) at 
>>driver.c:614
>>#3  0x0805ae82 in do_session (ctl=0x808d2d8, proto=0x8071da0, maxfetch=0) 
>>at driver.c:1449
>>#4  0x0805b39d in do_protocol (ctl=0x808d2d8, proto=0x8071da0) at 
>>driver.c:1622
>>#5  0x0804f81a in doPOP3 (ctl=0x808d2d8) at pop3.c:1215
>>#6  0x08054c11 in query_host (ctl=0x808d2d8) at fetchmail.c:1373
>>#7  0x08052c26 in main (argc=4, argv=0xbff80bd4) at fetchmail.c:646
>>
>>It is downloading mail from POP3.
> 
> 
> I seem to be unable to reproduce this. I've tried the POP3 modules of
> Dovecot 0.99.14 and some older Courier-IMAP.
> 
> What upstream server software are you using,
> who built your fetchmail version,
> and what is your .fetchmailrc?

I don't know what the upstream server runs. Is there a way of figuring this 
out through the server? It is an ISP POP3 server running at 
aap.businessserve.co.uk

I am running Gentoo Linux which compiles fetchmail from source, however I also 
reproduced the bug on an unmodified locally compiled fetchmail-6.3.0

My .fetchmailrc :

poll aap.businessserve.co.uk proto pop3 no dns localdomains mydomain.com:
envelope "Delivered-To:"
user xxx with pass xxx to * here keep

>>--- fetchmail-6.2.5/transact.c.orig	2005-12-05 15:25:54.000000000 +0000
>>+++ fetchmail-6.2.5/transact.c	2005-12-05 16:16:45.000000000 +0000
>>@@ -511,7 +511,7 @@ int readheaders(int sock,
>> 	    }
>> 
>> 	    /* check for end of headers */
>>-	    if (end_of_header(line))
>>+	    if (msgblk.headers && end_of_header(line))
>> 	    {
>> 		if (linelen != strlen (line))
>> 		    has_nuls = TRUE;
> 
> 
> What has "msgblk.headers" got to do with "line"? I'm not particular fond
> of such skewed checks, they'll come back some day to bite us.
> 

Ok, I'll try and explain better:

readheaders() is called.

readheaders() nulls out msgblk.headers and starts processing the mail.

The first line read is just a literal '\r\n', so we have line="\r\n" and 
linelen=2. We skip a couple of checks (line does not exceed MSGBUFSIZE, line 
is properly CRLF terminated), and we get down to line 520:

	    /* check for end of headers */
	    if (end_of_header(line))
	    {
		if (linelen != strlen (line))
		    has_nuls = TRUE;
		free(line);
		goto process_headers;
	    }

end_of_headers(line) succeeds - line *is* just a literal \r\n so it does look 
like the blank line inbetween headers and body. So we now jump to process_headers.

[ I just noticed that the crash occurs in a MULTIDROP-only section of code. 
Maybe this is why you can't reproduce it. ]

Working down the function from process_headers, we get down to line 953:

	MD5Update(&context, msgblk.headers, strlen(msgblk.headers));

As we haven't touched msgblk.headers since earlier, it is still NULL, so we 
call strlen(NULL) which causes a segfault.

Of course, there are other ways of circumventing this problem. I think my 
patch does have *some* sensible logic behind it - i.e. check that we do 
actually have headers before trying to figure out if the headers are ending, 
but I'll leave it to you if you can think of more appropriate ways.

Thanks,
Daniel

[fetchmail-devel] Re: fetchmail segfault on 'empty' mail

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

[resending to the list, too, with more information on what I've tried to
reproduce]

Please take everything to the berlios.de lists (you'll need to
subscribe there) - we plan to leave the ccil.org lists since nobody has
administrative access to them any more.

On Mon, 05 Dec 2005, Daniel Drake wrote:

> Hi,
> 
> I noticed that my fetchmail was segfaulting at the very start of a 
> particular mail message, with this trace:
> 
> #0  0xb7e67423 in strlen () from /lib/tls/libc.so.6
> #1  0x0805cded in readheaders (sock=6, fetchlen=0, reallen=0, 
> ctl=0x808d2d8, num=2, suppress_readbody=0xbff7c835 "")
>     at transact.c:920
> #2  0x080597df in fetch_messages (mailserver_socket=6, ctl=0x808d2d8, 
> count=272, msgsizes=0xbff7c7f0, maxfetch=0,
>     fetches=0xbff7e8c0, dispatches=0xbff7e8bc, deletions=0xbff7e8cc) at 
> driver.c:614
> #3  0x0805ae82 in do_session (ctl=0x808d2d8, proto=0x8071da0, maxfetch=0) 
> at driver.c:1449
> #4  0x0805b39d in do_protocol (ctl=0x808d2d8, proto=0x8071da0) at 
> driver.c:1622
> #5  0x0804f81a in doPOP3 (ctl=0x808d2d8) at pop3.c:1215
> #6  0x08054c11 in query_host (ctl=0x808d2d8) at fetchmail.c:1373
> #7  0x08052c26 in main (argc=4, argv=0xbff80bd4) at fetchmail.c:646
> 
> It is downloading mail from POP3.

I seem to be unable to reproduce this. I've tried the POP3 modules of
Dovecot 0.99.14 and some older Courier-IMAP.

What upstream server software are you using,
who built your fetchmail version,
and what is your .fetchmailrc?

> --- fetchmail-6.2.5/transact.c.orig	2005-12-05 15:25:54.000000000 +0000
> +++ fetchmail-6.2.5/transact.c	2005-12-05 16:16:45.000000000 +0000
> @@ -511,7 +511,7 @@ int readheaders(int sock,
>  	    }
>  
>  	    /* check for end of headers */
> -	    if (end_of_header(line))
> +	    if (msgblk.headers && end_of_header(line))
>  	    {
>  		if (linelen != strlen (line))
>  		    has_nuls = TRUE;

What has "msgblk.headers" got to do with "line"? I'm not particular fond
of such skewed checks, they'll come back some day to bite us.

-- 
Matthias Andree

Re: [fetchmail-devel] 6.3.0 is out - draft announcement

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

Nico Golde <ni...@ng...> writes:

> * Rob Funk <rf...@fu...> [2005-12-05 19:23]:
> [...] 
>> Changes between Fetchmail 6.2.5 and 6.3.0:
>> The --netsec/-T options were removed. The --smtphost is 
>> now always "localhost". fetchmail now uses automake. 
>
> Do you really think the autohell is an improvement?

automake surely is, it gives users and packagers a pretty well-known
default set of targets and overrides (DESTDIR, prefix, mandir and
whatnot), handles conditionals without scratching your ear with your
toes.

I'm a bit more critical about autoconf since it's plain bloatware rather
than using shell functions, but fetchmail has been using this for a long
time (if not from the first day).

auto* "hell" as you call it will certainly not go away before 7.0.0. If
a good and leaner build system has stabilized by then, we might go for it.

-- 
Matthias Andree

Re: [fetchmail-devel] 6.3.0 is out - draft announcement

[Nico G. <ni...@ng...>]

Hallo Rob,

* Rob Funk <rf...@fu...> [2005-12-05 19:23]:
[...] 
> Changes between Fetchmail 6.2.5 and 6.3.0:
> The --netsec/-T options were removed. The --smtphost is 
> now always "localhost". fetchmail now uses automake. 

Do you really think the autohell is an improvement?
[...] 
Regards Nico
-- 
Nico Golde - JAB: ni...@ja... | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org
Forget about that mouse with 3/4/5 buttons -
gimme a keyboard with 103/104/105 keys!

Re: [fetchmail-devel] 6.3.0 is out - draft announcement

[Rob F. <rf...@fu...>]

Matthias Andree wrote:
> Rob Funk <rf...@fu...> writes:
> > Matthias Andree wrote:
> >> I have not yet managed to write a decent release announcement and
> >> rework every tiny bit of the web page - help welcome.
> >>
> >> I also have not yet announced this 6.3.0 widely (freshmeat, other
> >> mailing lists) - we'll see how the first downloaders receive this
> >> software and if we need to do 6.3.1 quickly or not.
> >
> > Anything in particular you do or don't want to see in an announcement?
>
> Nothing special. There are various bits you can collect from:
>
> 
<http://freshmeat.net/projects/fetchmail/?branch_id=2635&release_id=213450> 
<http://fetchmail.berlios.de/> (newsflash)
> <http://developer.berlios.de/forum/forum.php?forum_id=16515>

OK, I've used those plus a small paragraph about the transition from ESR in 
the attached draft.  Also a few other minor edits.  Let me know what you 
think...

-- 
==============================| "A slice of life isn't the whole cake
 Rob Funk <rf...@fu...> | One tooth will never make a full grin"
 http://www.funknet.net/rfunk |    -- Chris Mars, "Stuck in Rewind"

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

[<no...@be...>]

Patch #740 has been updated. 

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

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

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

[fetchmail-devel] [Patch #738] old fetchmail -5.2.8 PCRE patch from ibiblio.org

[<no...@be...>]

Patch #738 has been updated. 

Project: fetchmail
Category: None
Status: Open
Submitted by: m-a
Assigned to : none
Summary: old fetchmail -5.2.8 PCRE patch from ibiblio.org

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

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

[fetchmail-devel] Please remove older system/mail/pop[/fetchmail] versions

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

Greetings, dear Ibiblio keepers,

I have just uploaded fetchmail-6.3.0.tar.bz2 and fetchmail.lsm.

I have noticed that the system/mail/pop directory contains both a
fetchmail subdirectory and heaps of old fetchmail versions. To the best
of my knowledge, all versions prior to 6.2.5.2 have remotely exploitable
security bugs in the POP3 UIDL code (older versions may have even more
bugs), and all versions prior to 6.2.5.4 (which I am not going to
upload unless you ask me to) or 6.3.0 expose the local password while
"fetchmailconf" writes the configuration, unless the umask is 077.

The fetchmail_pcre files are safe and should stay. The tarballs and
RPM however are unsafe. I therefore ask you to remove

- the entire system/mail/pop/fetchmail directory and

- these files from the directory system/mail/pop
  (again, please keep fetchmail_pcre*, someone might want to update it
  some day):

fetchmail-5.9.13-1.i386.rpm
fetchmail-5.9.13-1.src.rpm
fetchmail-5.9.13.tar.gz
fetchmail-5.9.14-1.i386.rpm
fetchmail-5.9.14-1.lsm
fetchmail-5.9.14-1.src.rpm
fetchmail-5.9.14.tar.gz
fetchmail-6.1.0-1.i386.rpm
fetchmail-6.1.0-1.src.rpm
fetchmail-6.1.0.tar.gz
fetchmail-6.1.1-1.i386.rpm
fetchmail-6.1.1-1.src.rpm
fetchmail-6.1.1.tar.gz
fetchmail-6.1.2-1.i386.rpm
fetchmail-6.1.2-1.src.rpm
fetchmail-6.1.2.tar.gz
fetchmail-6.2.2-1.i386.rpm
fetchmail-6.2.2-1.src.rpm
fetchmail-6.2.2.tar.gz
fetchmail-FAQ.html
fetchmail.README
fetchmail.lsm

-- 
Matthias Andree

[fetchmail-devel] New PO Template file for `fetchmail'

[Translation P. R. <tra...@ir...>]

Hello, gentle maintainer. This is a message from the Translation
Project robot.

A new PO Template file, for programs using the textual domain
`fetchmail', has just been made available to language teams for
translation, and a copy is available as:
>    http://www.iro.umontreal.ca/translation/domains/POT/fetchmail-6.3.0.pot

The file should soon be made available in mirror sites as:

>    ftp://ftp.unex.es/pub/gnu-i18n/po/domains/POT/fetchmail-6.3.0.pot
>    http://translation.sf.net/domains/POT/fetchmail-6.3.0.pot
>    ftp://tiger.informatik.hu-berlin.de/pub/po/domains/POT/fetchmail-6.3.0.pot


In your releases, this file is usually found as `po/fetchmail.pot'.
It is created or updated automatically at `make dist' time, or
whenever you run `make update-po' in the `po/' subdirectory.  Whenever
you have a distribution ready which holds a newer PO Template, please
send the URL of this distribution to the address below.  The
distribution could be a pretest or a snapshot, it does not even have
to compile.  This is to be used by translators, when they need to get
some translation context from your sources.

Within the Translation Project, each PO Template file should have
different version numbers, but since it is not OK to have two
different distributions having same version numbers, this is not a
problem in practice.
Here is the URL information which has just been provided to translators for
your package.  Please inform the translation coordinator, at the address
given below, if the information does not appear to be adequate or current:

>    http://download.berlios.de/fetchmail/fetchmail-6.3.0.tar.bz2

Translated PO files will later be automatically e-mailed to you.

Thanks for your collaboration,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                mailto:tra...@ir...

Re: [fetchmail-devel] 6.3.0 is out - SVN overview

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

Rob Funk <rf...@fu...> writes:

> Matthias Andree wrote:
>> with the release of 6.3.0 on BerliOS,
>
> Woohoo!  Thanks for all your hard work on making that happen!
>
>> I have not yet managed to write a decent release announcement and rework
>> every tiny bit of the web page - help welcome.
>>
>> I also have not yet announced this 6.3.0 widely (freshmeat, other
>> mailing lists) - we'll see how the first downloaders receive this
>> software and if we need to do 6.3.1 quickly or not.
>
> Anything in particular you do or don't want to see in an announcement?

Nothing special. There are various bits you can collect from:

<http://freshmeat.net/projects/fetchmail/?branch_id=2635&release_id=213450>
<http://fetchmail.berlios.de/> (newsflash)
<http://developer.berlios.de/forum/forum.php?forum_id=16515>

-- 
Matthias Andree

Re: [fetchmail-devel] 6.3.0 is out - SVN overview

[Rob F. <rf...@fu...>]

Matthias Andree wrote:
> with the release of 6.3.0 on BerliOS,

Woohoo!  Thanks for all your hard work on making that happen!

> I have not yet managed to write a decent release announcement and rework
> every tiny bit of the web page - help welcome.
>
> I also have not yet announced this 6.3.0 widely (freshmeat, other
> mailing lists) - we'll see how the first downloaders receive this
> software and if we need to do 6.3.1 quickly or not.

Anything in particular you do or don't want to see in an announcement?

-- 
==============================|   "A microscope locked in on one point
 Rob Funk <rf...@fu...> |Never sees what kind of room that it's in"
 http://www.funknet.net/rfunk |    -- Chris Mars, "Stuck in Rewind"

[fetchmail-devel] 6.3.0 is out - SVN overview

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

Greetings,

with the release of 6.3.0 on BerliOS, I have made a few changes to SVN.

1. fetchmail-6.3.X versions are kept on
   https://decoy.wox.org/svn/fetchmail/branches/BRANCH_6-3. The 6.3.0
   release has been made from there. This branch should only receive
   documentation updates, well-tested and confirmed bug fixes, and
   translation updates.

2. I have tagged r4499 as
   https://decoy.wox.org/svn/fetchmail/tags/RELEASE_6-3-0 - running
   "make dist" on this branch should reproduce the release tarball with
   reasonable accuracy. I've used automake 1.9.6, autoconf 2.59, gettext
   0.14.3, flex 2.5.4 and bison 1.875 to build.

3. development for the future 6.4.0 version should take place on the
   trunk. We have outstanding feature patches, we still have some bugs
   to fix - some require changes of concept -, and todo.html and TODO
   (they do NOT have identical content at this time - unfortunately,
   we'll have to fix this, too!), see for instance
   <http://bugs.debian.org/fetchmail>. Some of the patches we still have
   pending are mentioned in the Wiki:
   <http://openfacts.berlios.de/index-en.phtml?title=FetchmailPatchReview>

4. I will not do major work on fetchmail this month and probably not
   next month either. Bugfixing 6.3.0 will suffice, and I expect we'll
   see quite a few bug reports come in now that people can hope for a
   fix.

I have not yet managed to write a decent release announcement and rework
every tiny bit of the web page - help welcome.

I also have not yet announced this 6.3.0 widely (freshmeat, other
mailing lists) - we'll see how the first downloaders receive this
software and if we need to do 6.3.1 quickly or not.

Happy fetching,

-- 
Matthias Andree

[fetchmail-devel] fetchmail 6.2.9-rc10 available (this is it, with minor bug fixes)

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings,

This is it - I have just released fetchmail 6.2.9-rc10, the final
release candidate before 6.3.0, with minor bug fixes.

Unless show stopping bugs are found, this will be released as fetchmail
6.3.0 on November 30. At that date, I will bump the version, copy
the SVN /trunk to /branches/BRANCH_6-3, tag RELEASE_6-3-0 and release.

I don't care for reports about cosmetic bugs unless accompanied by a
fix which is either trivial or otherwise obviously correct.

NOTE: Fetchmail used to have these translations, but unless someone
submits updated translation (.po) files to the Translation Project's
Robot (doesn't matter if for -rc9 or -rc10) and has it relayed to
fetchmail-devel by Wednesday UTC noon, these will be dropped from the
distribution as they lack too many translations and would result in a
horrible English/local language mix:

da      Danish
el      Greek
gl      Galician
pt_BR   Brazilian Portuguese
sk      Slovak
tr      Turkish

My special thanks go to Jakub Bogusz, Pavel Maryanov and Takeshi
Hamasaki for their efforts to get the Polish, Russian and Japanese
translations updated.

For distributors, please upload this to every distribution that you have
where small changes in behavior are allowed, to expose this to wider
testing, and put this through your build farms.

Changes since -rc9 are:
* Fix installation without Python. Sunil Shetye, reported by Peter Church. (MA)
* Update Japanese translation. Fixes Bug#329342, Takeshi Hamasaki. (MA)
* Fix imap.c size safeguard that broke on x86_64 architecture. Matthias Andree
* The FAQ is now available for duplex DIN A4 printing in PDF format.
  Don't bother to ask for a Letter version, I don't care.  Matthias Andree
* Man page: Use \- in the manual page where appropriate so that copy & paste
  works.  I hope we got them all.  Héctor García, Matthias Andree.

The software is available from:
<https://developer.berlios.de/project/showfiles.php?group_id=1824&release_id=8158>
<http://home.pages.de/~mandree/fetchmail/>

Regards,

- -- 
Matthias Andree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFDik3avmGDOQUufZURAkcpAKCGUZ9KyG/hMJJtSTkNxq0zg+J3qgCfV76R
pxHVr2GuKSSEXzhTW42BQPs=
=cUee
-----END PGP SIGNATURE-----

Re: [fetchmail-devel] New Japanese PO file for `fetchmail'

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

Translation Project Robot schrieb am 2005-11-25:

> Hello, gentle maintainer. This is a message from the Translation
> Project robot.
> 
> A revised PO file, for programs using the textual domain `fetchmail',
> has been submitted by the team of translators taking care of the
> Japanese language.  This particular file, along with all other PO
> files pertaining to the same textual domain, is available as:
> >    http://www.iro.umontreal.ca/translation/maint/fetchmail/ja.po

Very well, thanks to Takeshi Hamasaki. fetchmail 6.3.0 will ship with an
up-to-date translation.

-- 
Matthias Andree

[fetchmail-devel] New Japanese PO file for `fetchmail'

[Translation P. R. <tra...@ir...>]

Hello, gentle maintainer. This is a message from the Translation
Project robot.

A revised PO file, for programs using the textual domain `fetchmail',
has been submitted by the team of translators taking care of the
Japanese language.  This particular file, along with all other PO
files pertaining to the same textual domain, is available as:
>    http://www.iro.umontreal.ca/translation/maint/fetchmail/ja.po

The file should soon be made available in mirror sites as:

>    ftp://ftp.unex.es/pub/gnu-i18n/po/maint/fetchmail/ja.po
>    http://translation.sf.net/maint/fetchmail/ja.po
>    ftp://tiger.informatik.hu-berlin.de/pub/po/maint/fetchmail/ja.po

This file has already been sent to you separately on 2005-11-25,
as a MIME invoice unpacking the file `fetchmail-6.2.9-rc9.ja.po'.

The following HTML page should also be updated by tomorrow.

>    http://www.iro.umontreal.ca/translation/HTML/domain-fetchmail.html

Please consider including all PO files, as they stand, in the `po/'
subdirectory of your next release of programs using that textual domain,
whether it is official or pretest.  Whenever you have a distribution ready
which holds a newer PO Template, please send the URL of this distribution
to the address below.  The distribution could be a pretest or a snapshot,
it does not even have to compile.  This is to be used by translators,
when they need to get some translation context from your sources.

Within the Translation Project, each PO Template file should have different
version numbers, but since it is not OK to have two different distributions
using same version numbers, this is not a problem in practice.

Contact me if any question arises.  Thanks for your collaboration,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                mailto:tra...@ir...

[fetchmail-devel] New Japanese PO file for `fetchmail'

[Translation P. R. <tra...@ir...>]

Hello, gentle maintainer. This is a message from the Translation
Project robot.

A revised PO file, for programs using the textual domain `fetchmail',
has been submitted by the team of translators taking care of the
Japanese language.  This particular file, along with all other PO
files pertaining to the same textual domain, is available as:
>    http://www.iro.umontreal.ca/translation/maint/fetchmail/ja.po

The file should soon be made available in mirror sites as:

>    ftp://ftp.unex.es/pub/gnu-i18n/po/maint/fetchmail/ja.po
>    http://translation.sf.net/maint/fetchmail/ja.po
>    ftp://tiger.informatik.hu-berlin.de/pub/po/maint/fetchmail/ja.po

This file has already been sent to you separately on 2005-11-25,
as a MIME invoice unpacking the file `fetchmail-6.2.9-rc9.ja.po'.

The following HTML page should also be updated by tomorrow.

>    http://www.iro.umontreal.ca/translation/HTML/domain-fetchmail.html

Please consider including all PO files, as they stand, in the `po/'
subdirectory of your next release of programs using that textual domain,
whether it is official or pretest.  Whenever you have a distribution ready
which holds a newer PO Template, please send the URL of this distribution
to the address below.  The distribution could be a pretest or a snapshot,
it does not even have to compile.  This is to be used by translators,
when they need to get some translation context from your sources.

Within the Translation Project, each PO Template file should have different
version numbers, but since it is not OK to have two different distributions
using same version numbers, this is not a problem in practice.

Contact me if any question arises.  Thanks for your collaboration,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                mailto:tra...@ir...