fetchmail-devel — Development related discussion

Re: [fetchmail-devel] [Patch] close ssl sockets

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

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

> I attached a patch for:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301964

I'm a bit chary about merging a patch that is labelled "Tentative" (in
the patch) or "It causes fetchmail to try to close the socket _twice_
(once as mailserver_socket and once as mailserver_socket_temp), but at
least it works." (in the bug report).

Someone going to take this and find an improved version that doesn't
have the double-close bug?

-- 
Matthias Andree

Re: [fetchmail-devel] what about message delimiter

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

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

> I have a problem with the following bug:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287215
> Can someone explain it and tell me if it's a real bug?

Hard to say if (1) it's a bug, (2) it still persists (the bug was filed
against an ancient version, 5.9.11) - the message alone just means the
server sent a malformed or truncated message over the wire, that had the
"CRLF.CRLF" before the blank line that delimits the body from the header
had been seen. Perhaps the POP3 server has a broken TOP
implementation. Who knows. A bit more detail wouldn't hurt...

It might be that fetchmail doesn't recover properly, someone would have
to find out.  Perhaps the original reporter, Martin A. Hansen, can
update to the version that shipped with sarge and retry, and if it
persists, show a log of a run with LC_ALL=C and fetchmail -vv?

-- 
Matthias Andree

Re: [fetchmail-devel] [PATCH] double @

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

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

> please include the patch on:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272289

Merged with the #ifdefs removed. We'll substitute trio_snprintf on
systems that don't have a working snprintf, in order not to take risks.

-- 
Matthias Andree

Re: [fetchmail-devel] [PATCH] spanish translation

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

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

> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286044

Merged, with one fix (elminiado -> eliminado).

-- 
Matthias Andree

Re: [fetchmail-devel] [PATCH] german translation file

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

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

> please include the attached patch for the german translation

Merged, thanks.

-- 
Matthias Andree

[fetchmail-devel] [PATCH] spanish translation

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

HI,
please include the patch from:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286044
regards and thanks
nico

-- 
Nico Golde - JAB: ni...@ja... | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred

[fetchmail-devel] [Patch] close ssl sockets

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

Hi,
I attached a patch for:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301964
Regards Nico

-- 
Nico Golde - JAB: ni...@ja... | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred

[fetchmail-devel] [PATCH] double @

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

Hi,
please include the patch on:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272289
thanks
nico

-- 
Nico Golde - JAB: ni...@ja... | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred

[fetchmail-devel] [PATCH] german translation file

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

Hi,
please include the attached patch for the german translation
file.
I checked it.
Regards Nico

-- 
Nico Golde - JAB: ni...@ja... | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred

[fetchmail-devel] what about message delimiter

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

Hi,
I have a problem with the following bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287215
Can someone explain it and tell me if it's a real bug?
regards and thanks
nico

-- 
Nico Golde - JAB: ni...@ja... | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred

Re: [fetchmail-devel] fetchmail bug - patch

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

Nico Golde <ni...@ng...> wrote, on fet...@li...:

> can you please include the following patch:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=285934

The patch and bug report are bogus. GCC 4/i386 compiles vanilla
fetchmail 6.2.5 as well as the current SVN fetchmail without problems,
and neither has such a nested SMTP_auth_error implementation.

Please remove from Debian all patches that break smtp.c.

-- 
Matthias Andree

[fetchmail-devel] fetchmail bug - patch

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

hi,
can you please include the following patch:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=285934
regards nico

-- 
Nico Golde - JAB: ni...@ja... | GPG: 1024D/73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred

Re: [fetchmail-devel] [PATCH] Fix handling of default port in fetchmailconf

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

Miloslav Trmac <mi...@re...> writes:

> The attached patch fixes this.

Whoops, I hit the "send" keys too fast, so here goes:
Thank you for the patch.

-- 
Matthias Andree

Re: [fetchmail-devel] [PATCH] Fix handling of default port in fetchmailconf

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

Miloslav Trmac <mi...@re...> writes:

> When 'port' is a string, it defaults to None; fetchmailconf can't
> handle that and writes 'port None' to the output config file if the
> server entry is not edited, see
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55623
> The attached patch fixes this.

I have committed your patch to the SVN repository, to appear in the next
release.

-- 
Matthias Andree

[fetchmail-devel] [PATCH] Fix handling of default port in fetchmailconf

[Miloslav T. <mi...@re...>]

Hello,
The 'port' setting used to be an integer, now it can be an integer
or a string, depending on the presence of IPv6 support.  fetchmailconf
assumes 'port' is an integer, though.

When 'port' is a string, it defaults to None; fetchmailconf can't
handle that and writes 'port None' to the output config file if the
server entry is not edited, see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55623
The attached patch fixes this.

Note that fetchmailconf still doesn't support other string values for
'port', even with this patch.
	Mirek

Re: [fetchmail-devel] sleep(3) @ pop3.c

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

On Tue, 17 May 2005, Rob Funk wrote:

> Yeah, I'm not at all suggesting we put the sleep back unless we discover an 
> in-use server that needs it.  And even then, detecting that server would be 
> best.

I'm even inclined to first try to have the server fixed, before
implementing workarounds.

fetchmail could then print a warning with a pointer to the solution
(knowledgebase, patch, etc.) that the user can forward to his ISP's
support division.

I believe in standards compliance.

-- 
Matthias Andree

Re: [fetchmail-devel] sleep(3) @ pop3.c

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

Matthias Andree wrote:
> Rob Funk <rf...@fu...> writes:
> > I'm not sure whether this is the Right Thing or not, but I'm pretty
> > sure that massive single-file mboxes are NOT the Right Thing, much less
> > POP servers that return +OK before they're really ready.
>
> I'm willing to risk switching off this sleep() for reasons I posted to
> fetchmail-friends, particularly insufficient information what this used
> to be good for eight years ago. The software that needed the workaround
> might be dead since 2001 or so... we need to try to find out
> unfortunately.

Yeah, I'm not at all suggesting we put the sleep back unless we discover an 
in-use server that needs it.  And even then, detecting that server would be 
best.

-- 
==============================| "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"

Re: [fetchmail-devel] sleep(3) @ pop3.c

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

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

> I'm not sure whether this is the Right Thing or not, but I'm pretty sure 
> that massive single-file mboxes are NOT the Right Thing, much less POP 
> servers that return +OK before they're really ready.

I'm willing to risk switching off this sleep() for reasons I posted to
fetchmail-friends, particularly insufficient information what this used
to be good for eight years ago. The software that needed the workaround
might be dead since 2001 or so... we need to try to find out
unfortunately.

-- 
Matthias Andree

Re: Re: [fetchmail-devel] sleep(3) @ pop3.c

[<sp...@po...>]

Użytkownik Rob Funk <rf...@fu...> napisał:

>> So, is there any way to add rc.file option which allow users to change
>> this delay from 3 to any other number including 0?
>
>The current development code (i.e. what will become the next release) 
>doesn\'t sleep there at all unless a flag is set at compile time:

Thank You

Re: [fetchmail-devel] sleep(3) @ pop3.c

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

sp...@po... wrote:
> I understand that You are trying to help users with bad pop3 servers.
> But I know my pop3 server (popa3d) and it will work fine without any
> delay after authentication.
>
> So, is there any way to add rc.file option which allow users to change
> this delay from 3 to any other number including 0?

The current development code (i.e. what will become the next release) 
doesn't sleep there at all unless a flag is set at compile time:

/* Disable the sleep. Based on patch by Brian Candler 
2004-04-19/2004-11-08,
 * accepted by Matthias Andree.
 *
 * Rationale: the server must have locked the spool before returning +OK;
 * this sleep just wastes time and hence, for modem and GSM CSD users, 
money. */
#ifdef WANT_BOGUS
    /*
     * Empirical experience shows some server/OS combinations
     * may need a brief pause even after any lockfiles on the
     * server are released, to give the server time to finish
     * copying back very large mailfolders from the temp-file...
     * this is only ever an issue with extremely large mailboxes.
     */
    sleep(3); /* to be _really_ safe, probably need sleep(5)! */
#endif


I'm not sure whether this is the Right Thing or not, but I'm pretty sure 
that massive single-file mboxes are NOT the Right Thing, much less POP 
servers that return +OK before they're really ready.

-- 
==============================|   "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] sleep(3) @ pop3.c

[<sp...@po...>]

Hi fetchmail-devel,

I understand that You are trying to help users with bad pop3 servers.
But I know my pop3 server (popa3d) and it will work fine without any delay after authentication.

So, is there any way to add rc.file option which allow users to change this delay from 3 to any other number including 0?

Regards

[fetchmail-devel] New Catalan 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
Catalan 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/ca.po

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

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

This file has already been sent to you separately on 2005-04-27,
as a MIME invoice unpacking the file `fetchmail-6.2.5.992.ca.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 Spanish 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
Spanish 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/es.po

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

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

This file has already been sent to you separately on 2005-04-26,
as a MIME invoice unpacking the file `fetchmail-6.2.5.992.es.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 Polish 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
Polish 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/pl.po

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

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

This file has already been sent to you separately on 2005-04-26,
as a MIME invoice unpacking the file `fetchmail-6.2.5.992.pl.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 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.2.5.992.pot

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

>    ftp://ftp.unex.es/pub/gnu-i18n/po/domains/POT/fetchmail-6.2.5.992.pot
>    http://translation.sf.net/domains/POT/fetchmail-6.2.5.992.pot
>    ftp://tiger.informatik.hu-berlin.de/pub/po/domains/POT/fetchmail-6.2.5.992.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://home.pages.de/~mandree/tmp/fetchmail-6.2.5.992.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...