fetchmail-devel — Development related discussion

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

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

Translation Project Robot <tra...@ir...> writes:

> 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
> Albanian 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/sq.po

I have added the file to the fetchmail Subversion repository.

-- 
Matthias Andree

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

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

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

This file has already been sent to you separately on 2005-04-25,
as a MIME invoice unpacking the file `fetchmail-6.2.5.991.sq.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...

Re: [fetchmail-devel] Reports of mail loss caused by fetchmail (6.2.5) on comp.mail.imap

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

Rob MacGregor <rob...@gm...> writes:

> Anybody who's still working on code may want to look at the following
> thread on comp.mail.imap (http://tinyurl.com/akl58 - links to
> groups.google.com).  Subject for the paranoid is "lost mail with
> fetchmail and cyrus" :)

Thanks for the pointer - your support of both users and developers
is priceless, thanks a lot.

The report and following analysis is bogus for the better part, the only
valid element is that Cyrus is right in complaining about
MAIL FROM: <...>, the syntax is MAIL FROM:<...> without blank.

Rob Funk merged the patch below last year to fix the problem - about
time we get to releasing 6.3.0 now.

The current code looks a bit different, as I have killed all
HAVE_SNPRINTF and imported Trio snprintf as replacement for those
decrepit systems that don't have snprintf.

(Rob sent me the passwords (not many) of the test accounts, but I
haven't yet had the time to check.)

------------------------------------------------------------------------
r3925 | rfunk | 2004-07-21 19:05:58 +0200 (Wed, 21 Jul 2004) | 1 line

Remove space after "MAIL FROM:" (patch from Phil Endecott)
------------------------------------------------------------------------
Index: sink.c
===================================================================
--- sink.c	(Revision 3924)
+++ sink.c	(Revision 3925)
@@ -721,7 +721,7 @@
 
     /* see the ap computation under the SMTP branch */
     fprintf(sinkfp, 
-	    "MAIL FROM: %s", (msg->return_path[0]) ? msg->return_path : user);
+	    "MAIL FROM:%s", (msg->return_path[0]) ? msg->return_path : user);
 
     if (ctl->pass8bits || (ctl->mimemsg & MSG_IS_8BIT))
 	fputs(" BODY=8BITMIME", sinkfp);
Index: smtp.c
===================================================================
--- smtp.c	(Revision 3924)
+++ smtp.c	(Revision 3925)
@@ -232,13 +232,13 @@
     int ok;
     char buf[MSGBUFSIZE];
 
-    if (strchr(from, '<'))
+    if (from[0]=='<')
 #ifdef HAVE_SNPRINTF
 	snprintf(buf, sizeof(buf),
 #else
 	sprintf(buf,
 #endif /* HAVE_SNPRINTF */
-		"MAIL FROM: %s", from);
+		"MAIL FROM:%s", from);
     else
 #ifdef HAVE_SNPRINTF
     snprintf(buf, sizeof(buf),


-- 
Matthias Andree

[fetchmail-devel] Reports of mail loss caused by fetchmail (6.2.5) on comp.mail.imap

[Rob M. <rob...@gm...>]

Anybody who's still working on code may want to look at the following
thread on comp.mail.imap (http://tinyurl.com/akl58 - links to
groups.google.com).  Subject for the paranoid is "lost mail with
fetchmail and cyrus" :)

The main problem seems to be fetchmail inserting a space after FROM:
when the sender is <>, causing Cyrus IMAP to barf.  However the email
is then deleted by fetchmail:

fetchmail: LMTP> MAIL FROM: <> BODY=8BITMIME SIZE=5481
fetchmail: LMTP< 501 5.5.4 Syntax error in parameters
fetchmail: LMTP error: 501 5.5.4 Syntax error in parameters
fetchmail: LMTP> RSET
fetchmail: LMTP< 250 2.0.0 ok
... flushed
fetchmail: POP3> DELE 1
fetchmail: POP3< +OK Message 1 has been deleted. 

I've advised the posters to contact this list with as much detail as
they can, but thought I'd pass this on just in case they don't.

I have 6.2.5 installed on a system with Cyrus IMAP 2.2.12 installed
and can test things out if others don't have access.

-- 
                 Please keep list traffic on the list.
Rob MacGregor
      Whoever fights monsters should see to it that in the process he 
        doesn't become a monster.                  Friedrich Nietzsche

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

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

Translation Project Robot <tra...@ir...> writes:

> 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

...

> 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

...

I have merged these into the SVN repository.

-- 
Matthias Andree

[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-16,
as a MIME invoice unpacking the file `fetchmail-6.2.5.991.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-15,
as a MIME invoice unpacking the file `fetchmail-6.2.5.991.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.991.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.991.pot
>    http://translation.sf.net/domains/POT/fetchmail-6.2.5.991.pot
>    ftp://tiger.informatik.hu-berlin.de/pub/po/domains/POT/fetchmail-6.2.5.991.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.991.tar.gz

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

[fetchmail-devel] Re: fetchmail domain migration

[Karl E. <ke...@su...>]

Matthias Andree <mat...@gm...> writes:

> This is a resent message as my previous copy seems to have been lost in
> Nirvana at iro.umontreal.ca.

Sorry for the delay :-(  Thanks for the notification!

> fetchmail is in the process of being handed over to new maintainers, and
> so we'd like to have the fetchmail domain entry changed as shown below.
>
> I'll be translating fetchmail for the "de" (German) team but given I
> have SVN access, I can commit directly, so I mark <ext>de. Not sure if I
> need a translator entry.

In this case a translator entry is not required for you.

> --- registry.sgml	2005-02-25 15:48:32.000000000 +0100
> +++ registry.sgml.new	2005-03-01 20:58:53.000000000 +0100
> @@ -234,11 +234,11 @@
>     <note>This is a compendium like textdomain
>  
>    <domain>fetchmail
> -   <mailto>es...@th...
> -   <keep>6.0.0<keep>6.1.3<keep>6.2.0<keep>6.2.4
> +   <mailto>fet...@li...
> +   <keep>6.2.0<keep>6.2.4<keep>6.2.5
>     <autosend>
>     <url>http://www.catb.org/~esr/fetchmail/fetchmail-6.2.5.tar.gz
> -   <ext>cs<ext>pt_BR
> +   <ext>de
>     <remark>was: http://www.tuxedo.org/~esr/fetchmail/fetchmail-6.2.2.tar.gz
>     <remark>XXX: gl,es is also initial
>     <remark>Keep more versions than usual because of strange version number scheme

I'm going to install the following entry:

  <domain>fetchmail
   <mailto>fet...@li...
   <keep>6.2.0<keep>6.2.40<keep>6.2.5
   <autosend>
   <url>http://www.catb.org/~esr/fetchmail/fetchmail-6.2.5.tar.gz
   <ext>de
   <remark>Keep more versions than usual because of strange version number scheme


-- 
Key fingerprint = B2A3 AF2F CFC8 40B1 67EA  475A 5903 A21B 06EB 882E

Re: [fetchmail-devel] Re: [fetchmail]How can i download mails through CatchAll A/c.

[Rob M. <rob...@gm...>]

On 4/13/05, Matthias Andree <mat...@gm...> wrote:
> 
> Looks excessive. I've considered making this an error instead and
> exit(23), but this would cause a deliberate regression in a patchlevel
> or minor release, hence now isn't the right time to do this.

Excessive is good - people might actually pay attention.

Has to be said though, I do prefer the exit() option.  That way it
really is "in their face" and may persuade them to do something.

-- 
                 Please keep list traffic on the list.
Rob MacGregor
      Whoever fights monsters should see to it that in the process he 
        doesn't become a monster.                  Friedrich Nietzsche

Re: [fetchmail-devel] Re: [fetchmail]How can i download mails through CatchAll A/c.

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

Rob MacGregor <rob...@gm...> writes:

> A further reference to the manual probably wouldn't help - this thread
> is pretty good proof that unless you hold people's hands they'll still
> fail.
>
> Maybe:
>
> fetchmail: warning: WARNING WARNING WARNING
> fetchmail: warning: multidrop for pop.example.org requires the
> envelope option to be set
> fetchmail: warning: Read "The use and abuse of multidrop mailboxes" in
> the man page
> fetchmail: warning: Do not ask for help if your mail is not correctly delivered
> fetchmail: warning: WARNING WARNING WARNING
>
> Possibly with a few more WARNING's :-)

Looks excessive. I've considered making this an error instead and
exit(23), but this would cause a deliberate regression in a patchlevel
or minor release, hence now isn't the right time to do this.

Plus, I don't have ESR's (or Rob Funk's) regression test data, so I
cannot check if this would break existing setups.

-- 
Matthias Andree

Re: [fetchmail-devel] Re: [fetchmail]How can i download mails through CatchAll A/c.

[Rob M. <rob...@gm...>]

On 4/13/05, Matthias Andree <mat...@gm...> wrote:
> 
> BTW, I have committed code to the SVN repository
> <http://mknod.org/svn/fetchmail/trunk> that prints a warning like this
> if multidrop configuration is attempted without envelope option:
> 
> fetchmail: warning: multidrop for pop.example.org requires envelope option!
> fetchmail: warning: Do not ask for support if all mail goes to postmaster!
> 
> To appear in the next release. I'm open for suggestions WRT improved wording.

A further reference to the manual probably wouldn't help - this thread
is pretty good proof that unless you hold people's hands they'll still
fail.

Maybe:

fetchmail: warning: WARNING WARNING WARNING
fetchmail: warning: multidrop for pop.example.org requires the
envelope option to be set
fetchmail: warning: Read "The use and abuse of multidrop mailboxes" in
the man page
fetchmail: warning: Do not ask for help if your mail is not correctly delivered
fetchmail: warning: WARNING WARNING WARNING

Possibly with a few more WARNING's :-)

-- 
                 Please keep list traffic on the list.
Rob MacGregor
      Whoever fights monsters should see to it that in the process he 
        doesn't become a monster.                  Friedrich Nietzsche

[fetchmail-devel] Re: [fetchmail]How can i download mails through CatchAll A/c.

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

Matthias Andree <mat...@gm...> writes:

> Nitin <ni...@in...> writes:
>
>> Thanks for reply.
>>
>> I have update fetchmail 6.2.5+INET6.
>>
>> My new .fetchmailrc config is :-
>>
>> poll qmail.india.net  with proto POP3
>> user nit...@in... there with password "nitin" is * here
>
> You **** MUST **** configure the "envelope" option.
>
> If the upstream does not keep the envelope in a header, you
> ***** CANNOT ***** use multidrop setups.
>
> See <http://home.pages.de/~mandree/mail/multidrop> for details.

BTW, I have committed code to the SVN repository
<http://mknod.org/svn/fetchmail/trunk> that prints a warning like this
if multidrop configuration is attempted without envelope option:

fetchmail: warning: multidrop for pop.example.org requires envelope option!
fetchmail: warning: Do not ask for support if all mail goes to postmaster!

To appear in the next release. I'm open for suggestions WRT improved wording.

-- 
Matthias Andree

[fetchmail-devel] fetchmail domain migration

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

This is a resent message as my previous copy seems to have been lost in
Nirvana at iro.umontreal.ca.
-----------------------------------------------------------------------

Greetings,

fetchmail is in the process of being handed over to new maintainers, and
so we'd like to have the fetchmail domain entry changed as shown below.

I'll be translating fetchmail for the "de" (German) team but given I
have SVN access, I can commit directly, so I mark <ext>de. Not sure if I
need a translator entry.

--- registry.sgml	2005-02-25 15:48:32.000000000 +0100
+++ registry.sgml.new	2005-03-01 20:58:53.000000000 +0100
@@ -234,11 +234,11 @@
    <note>This is a compendium like textdomain
 
   <domain>fetchmail
-   <mailto>es...@th...
-   <keep>6.0.0<keep>6.1.3<keep>6.2.0<keep>6.2.4
+   <mailto>fet...@li...
+   <keep>6.2.0<keep>6.2.4<keep>6.2.5
    <autosend>
    <url>http://www.catb.org/~esr/fetchmail/fetchmail-6.2.5.tar.gz
-   <ext>cs<ext>pt_BR
+   <ext>de
    <remark>was: http://www.tuxedo.org/~esr/fetchmail/fetchmail-6.2.2.tar.gz
    <remark>XXX: gl,es is also initial
    <remark>Keep more versions than usual because of strange version number scheme

-- 
Matthias Andree

[fetchmail-devel] pending patches?

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

Graham,

I don't recall the state on the two "Review in Progress" items at 
<http://openfacts.berlios.de/index-en.phtml?title=FetchmailPatchReview>
one was about your local Debian patch, or more precisely, what parts of
the Debian patch should move into the upstream. Are there any missing
from SVN?

TIA,

-- 
Matthias Andree

[fetchmail-devel] mknod.org maintenence

[Graham W. <gr...@mk...>]

mknod.org was inaccessible briefly yesterday as I migrated servers. The
old server was a Pentium 233 with 128 MB of memory and a 2.6G disk. The
new machine is a 1.8 GHz Athlon with 512 MB of memory and 30G of RAID-1.

Also, I'd like to make a note about backups. The Subversion repositories
are dumped nightly, and backups for the past seven days (in which
changes occurred) are stored. At some point in the near future I will
also begin to mirror backups to a machine offsite.

The latest backup will always be available on the web [1], should anyone
need to use them. Please don't download them unless you really intend to
use them!

[1] http://mknod.org/fetchmail/

-- 
gram

Re: [fetchmail-devel] [BUG] fetchmail hangs during pop3 pull after a mail with a null char

[David G. <da...@dg...>]

many moons ago (8 Nov 04) Matthias Andree wrote:

>David Greaves <da...@dg...> writes:
>
>  
>
>>Summary : fetchmail hangs during pop3 pull after a mail with a null
>>char.
>>    
>>
>
>Can you try the tarball from
>http://home.pages.de/~mandree/tmp/fetchmail-6.2.6.tar.bz2 and see if the
>problem persists? There have been several bugfixes since 6.2.5, the
>noteworthy documented at http://decoy.wox.org/svn/fetchmail/trunk/NEWS -
>just to make sure we aren't chasing a bug that's already fixed?
>
>NOTE the tarball there isn't the final 6.2.6 release tarball but a
>preliminary snapshot and may see further changes before being released
>as 6.2.6.
>
>Thanks in advance.
>  
>
Hi again Matthias :)

This was the reason I was upgrading to 6.2.5.991
I've included my original message in case you don't have a copy to hand.

I have a message in my pop queue with a null char in it (which is what 
triggers this).

There's a log below.

I can work around the problem if I "expunge 1" - but that's nasty.

As I said in my original message, I think it was sink.c calling smtp_ok 
- have you any suggestions as to where/how to debug this?

David

log:
# /usr/bin/fetchmail -N -v -v --nosyslog -f /etc/fetchmailrc
fetchmail: starting fetchmail 6.2.5.991 daemon
fetchmail: 6.2.5.991 querying pop3.ukfsn.org (protocol POP3) at Wed 23 
Mar 2005 11:57:08 AM GMT: poll started
fetchmail: POP3< +OK <ce2...@po...>
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< PIPELINING
fetchmail: POP3< TOP
fetchmail: POP3< USER
fetchmail: POP3< UIDL
fetchmail: POP3< STLS
fetchmail: POP3< .
fetchmail: POP3> USER dgreaves
fetchmail: POP3< +OK Tell me your password.
fetchmail: POP3> PASS *
fetchmail: POP3< +OK Welcome aboard! You have 22 messages.
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 22 105420
22 messages for dgreaves at pop3.ukfsn.org (105420 octets).
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 3982
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK Message follows

<snip some good pop'ing>

fetchmail: LMTP< 250 2.1.5 Ok
 flushed
fetchmail: POP3> DELE 2
fetchmail: POP3< +OK Done.
fetchmail: POP3> LIST 3
fetchmail: POP3< +OK 3 2852
fetchmail: POP3> RETR 3
fetchmail: POP3< +OK Message follows
reading message dgr...@po...:3 of 22 (2852 octets)
About to rewrite Return-Path: <ca...@ab...>
Rewritten version is Return-Path: <ca...@ab...>

About to rewrite From: Susan M.Taylor <ca...@ab...>
Rewritten version is From: Susan M.Taylor <ca...@ab...>

About to rewrite To: 64....@dg...
Rewritten version is To: 64....@dg...

fetchmail: forwarding to /var/imap/socket/lmtp
fetchmail: LMTP> MAIL FROM:<ca...@ab...> SIZE=2852
fetchmail: LMTP< 250 2.1.0 ok
fetchmail: LMTP> RCPT TO:<da...@dg...>
fetchmail: LMTP< 250 2.1.5 ok
fetchmail: LMTP> DATA
fetchmail: LMTP< 354 go ahead
#******************************************.**************************fetchmail: 
message dgr...@po...:3 was not the expected length (2947 
actual != 2852 expected)
fetchmail: LMTP>. (EOM)
fetchmail: LMTP< 554 5.6.0 Message contains NUL characters
fetchmail: SMTP< 220 willow.dgreaves.com ESMTP Exim 4.20 Wed, 23 Mar 
2005 11:57:11 +0000
fetchmail: SMTP> HELO localhost
fetchmail: SMTP< 250 willow.dgreaves.com Hello 
[IbwiAqeOpcFJkOALoy6jCLP6WNxrOhWp] at localhost.localdomain [127.0.0.1]
fetchmail: SMTP> MAIL FROM:<>
fetchmail: SMTP< 250 OK
fetchmail: SMTP> RCPT TO:<da...@dg...>
fetchmail: SMTP< 250 Accepted
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 Enter message, ending with "." on a line by itself
fetchmail: SMTP: (bounce-message body)
fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 OK id=1DE4U3-0008M5-Lv
fetchmail: SMTP> QUIT
fetchmail: SMTP< 221 willow.dgreaves.com closing connection
 flushed
fetchmail: POP3> DELE 3
fetchmail: POP3< +OK Done.
fetchmail: POP3> LIST 4
fetchmail: POP3< +OK 4 3583
fetchmail: POP3> RETR 4
fetchmail: POP3< +OK Message follows
reading message dgr...@po...:4 of 22 (3583 octets)
About to rewrite Return-Path: <co...@gu...>
Rewritten version is Return-Path: <co...@gu...>

About to rewrite From: Colin Guthrie <co...@gu...>
Rewritten version is From: Colin Guthrie <co...@gu...>

About to rewrite To: David Greaves <da...@dg...>
Rewritten version is To: David Greaves <da...@dg...>

fetchmail: forwarding to /var/imap/socket/lmtp
fetchmail: SMTP> MAIL FROM:<co...@gu...> BODY=7BIT SIZE=3583
fetchmail: SMTP< 250 2.1.0 ok
fetchmail: SMTP> RCPT TO:<da...@dg...>
fetchmail: SMTP< 250 2.1.5 ok
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 go ahead
#******************************.******************************fetchmail: 
message dgr...@po...:4 was not the expected length (3678 
actual != 3583 expected)
fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 2.1.5 Ok
 
<at this point fetchmail hangs...>

fetchmail: smtp listener protocol error
 not flushed
fetchmail: POP3> LIST 5

<and the server go bored of waiting>

fetchmail: POP3< -ERR Client has been idle for too long.
fetchmail: Client has been idle for too long.
fetchmail: POP3> QUIT
fetchmail: client/server protocol error while fetching from pop3.ukfsn.org

Re: [PATCH] Re: [fetchmail-devel] Re: 6.2.6 fails where 6.2.5 was OK

[David G. <da...@dg...>]

Matthias Andree wrote:

> You've got the patch backwards. Use "diff -ur OLDER NEWER".

sorry.

>Even reading it in the right direction, I don't see what this does - and
>how it could possibly fix your problem. use_ssl defaults to false,
>
use_ssl *should* default to false.

I didn't follow the logic through - it was an eyeballing of the use of 
an _ssl variable outside an SSL_ENABLE block.
It does actually fix the problem for me.

Once an 'obvious' bug fixed it for me I passed it on to you...
Anyway, I'm glad it's helped find a regression.

This code snippet was my debug test... I didn't know the insides of 
fetchmail well enough to assume anything else :)


    if (ctl->use_ssl == FLAG_FALSE) fprintf(stderr, "is FLAG_false\n");
    else fprintf(stderr, "use_ssl isn't FLAG_false\n");
   
    if (
#ifdef SSL_ENABLE
        (ctl->use_ssl != FLAG_FALSE) ||
#endif /* SSL_ENABLE (*/


fetchmail: 6.2.5.991 querying pop.freeserve.net (protocol POP3) at Sat 
19 Mar 2005 01:07:16 PMGMT: poll started
fetchmail: POP3< +OK connected to pop3 on 3002
use_ssl isn't FLAG_false
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR unknown command
fetchmail: unknown command
fetchmail: Repoll immediately on 
da...@in...@pop.freeserve.com
fetchmail: POP3< +OK connected to pop3 on 3212
use_ssl isn't FLAG_false
fetchmail: POP3> USER da...@in...
fetchmail: POP3< +OK name is a valid mailbox
fetchmail: POP3> PASS *
fetchmail: POP3< +OK user exist with that password

################################################
anyway.... I couldn't leave it at that :)


a context grep of use_ssl gives an interesting result in fetchmail.c:
fetchmail.c-#ifdef      SSL_ENABLE
fetchmail.c:        DEFAULT(ctl->use_ssl, FALSE);
fetchmail.c-        DEFAULT(ctl->sslcertck, FALSE);
fetchmail.c-#endif

so if SSL_ENABLE is not defined it's undefined.

So, I'm thinking my patch was right after all ;)

:-P  nyah!

David

Re: [fetchmail-devel] Re: 6.2.6 fails where 6.2.5 was OK

[David G. <da...@dg...>]

Matthias Andree wrote:

>The code is not up-to-date, and I don't see this problem when using my
>version against a server that does not support CAPA.
>  
>
thanks :)
well, since the problem occurs before the user/pass - feel free to use 
that bit of my fetchmailrc to see if you have the problem.

>May I ask you to try
>http://home.pages.de/~mandree/tmp/fetchmail-6.2.5.991.tar.bz2
>first and report here if your problem persists in 6.2.5.991?
>  
>
sure :-
fetchmail: 6.2.5.991 querying pop.freeserve.net (protocol POP3) at Sat 
19 Mar 2005 08:24:38 AMGMT: poll started
fetchmail: POP3< +OK connected to pop3 on 3107
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR unknown command
fetchmail: unknown command
fetchmail: Repoll immediately on 
da...@in...@pop.freeserve.com
fetchmail: POP3< +OK connected to pop3 on 3006
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR unknown command
fetchmail: unknown command

and now I have the up to date source, I'll take a quick look too...

David

[PATCH] Re: [fetchmail-devel] Re: 6.2.6 fails where 6.2.5 was OK

[David G. <da...@dg...>]

Matthias Andree wrote:

>The code is not up-to-date, and I don't see this problem when using my
>version against a server that does not support CAPA.
>
>May I ask you to try
>http://home.pages.de/~mandree/tmp/fetchmail-6.2.5.991.tar.bz2
>first and report here if your problem persists in 6.2.5.991?
>  
>
it does...

>That is newer code (2005-03-01) in spite of the lower version number
>(the "6.2.6" snapshot is from 2004-11-10).
>  
>
I didn't configure --with-ssl :)

I think this is the correct fix.

--- fetchmail-6.2.5.991-dg/pop3.c       Sat Mar 19 11:35:59 2005
+++ fetchmail-6.2.5.991/pop3.c  Sun Feb 27 20:19:35 2005
@@ -361,10 +361,7 @@ static int pop3_getauth(int sock, struct
         * These authentication methods are blessed by RFC1734,
         * describing the POP3 AUTHentication command.
         */
-       if (
-#ifdef SSL_ENABLE
-           (ctl->use_ssl != FLAG_FALSE) ||
-#endif /* SSL_ENABLE (*/
+       if ((ctl->use_ssl != FLAG_FALSE) ||
            (ctl->server.authenticate == A_ANY) ||
            (ctl->server.authenticate == A_GSSAPI) ||
            (ctl->server.authenticate == A_KERBEROS_V4) ||

Re: [fetchmail-devel] 6.2.6 fails where 6.2.5 was OK

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

[[
CC: Nalin Dahyabai

Nalin, as the list archives are down currently:

David Greaves originally reported that your patch that Eric S. Raymond
merged as "Nalin Dahyabai's fix for POP3 strong authentication" after
fetchmail-6.2.5 caused fetchmail to go into an unterminated loop when
the server rejected the CAPA command. If you can shed any light on your
patch that changed pop3.c like this, please do -- if this wasn't your
patch, ESR would take the blame for coalescing several patches under a
bogus comment.

--- pop3.c      (Revision 3872)
+++ pop3.c      (Revision 3873)
@@ -365,7 +365,12 @@
         * These authentication methods are blessed by RFC1734,
         * describing the POP3 AUTHentication command.
         */
-       if (ctl->server.authenticate == A_ANY)
+       if ((ctl->use_ssl != FLAG_FALSE) ||
+           (ctl->server.authenticate == A_ANY) ||
+           (ctl->server.authenticate == A_GSSAPI) ||
+           (ctl->server.authenticate == A_KERBEROS_V4) ||
+           (ctl->server.authenticate == A_OTP) ||
+           (ctl->server.authenticate == A_CRAM_MD5))
...
]]

[[
Rob,
I made inofficial snapshots from Subversion for testing on
2004-11-10, named fetchmail 6.2.6, and
2005-03-01, named fetchmail 6.2.5.991, for the translation project
These revealed the regression.

BTW, I have not yet heard back from the translation project :-((
]]

David Greaves <da...@dg...> writes:

> I'm upgrading from 6.2.5 to 6.2.6 and I've encountered a possible bug 
> where 6.2.6 resends a CAPA challenge even when the server doesn't 
> understand it. The ISP is a major UK one.

The problem is really that fetchmail replaces the server.authenticate
member, but the use_ssl flag overrides this. Besides that, FLAG_FALSE is
not a state that we can be in at this time, as the DEFAULT() macro in
fetchmail.c will have replaced it by FALSE at this time.

I don't currently see why an SSL-wrapped connection alone would require
CAPA, so I'll just remove this bogus check.

OTOH, this (code with patch) may still not be flawed because
falling back to USER/PASS when the user has configured a
more secure authentication mechanism is bogus and a security risk.

If the user configures something strong and it fails, so be it. I don't
see why we would use CAPA for anything but the _ANY, and I don't find
Nalin's post that got sent to ESR somewhen before January 2004, so I
presume the patch was sent privately.


Please try this band-aid patch:

Index: pop3.c
===================================================================
--- pop3.c	(Revision 4024)
+++ pop3.c	(Arbeitskopie)
@@ -361,8 +361,7 @@
 	 * These authentication methods are blessed by RFC1734,
 	 * describing the POP3 AUTHentication command.
 	 */
-	if ((ctl->use_ssl != FLAG_FALSE) ||
-	    (ctl->server.authenticate == A_ANY) ||
+	if ((ctl->server.authenticate == A_ANY) ||
 	    (ctl->server.authenticate == A_GSSAPI) ||
 	    (ctl->server.authenticate == A_KERBEROS_V4) ||
 	    (ctl->server.authenticate == A_OTP) ||


-- 
Matthias Andree

Re: [PATCH] Re: [fetchmail-devel] Re: 6.2.6 fails where 6.2.5 was OK

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

On Sat, 19 Mar 2005, David Greaves wrote:

> >That is newer code (2005-03-01) in spite of the lower version number
> >(the "6.2.6" snapshot is from 2004-11-10).
>
> I didn't configure --with-ssl :)
> 
> I think this is the correct fix.
> 
> --- fetchmail-6.2.5.991-dg/pop3.c       Sat Mar 19 11:35:59 2005
> +++ fetchmail-6.2.5.991/pop3.c  Sun Feb 27 20:19:35 2005
> @@ -361,10 +361,7 @@ static int pop3_getauth(int sock, struct
>         * These authentication methods are blessed by RFC1734,
>         * describing the POP3 AUTHentication command.
>         */
> -       if (
> -#ifdef SSL_ENABLE
> -           (ctl->use_ssl != FLAG_FALSE) ||
> -#endif /* SSL_ENABLE (*/
> +       if ((ctl->use_ssl != FLAG_FALSE) ||
>            (ctl->server.authenticate == A_ANY) ||
>            (ctl->server.authenticate == A_GSSAPI) ||
>            (ctl->server.authenticate == A_KERBEROS_V4) ||

You've got the patch backwards. Use "diff -ur OLDER NEWER".

Even reading it in the right direction, I don't see what this does - and
how it could possibly fix your problem. use_ssl defaults to false, and
the bug also shows with SSL enabled at compile time and unused in the
configuration.

I can reproduce this on my computer even with the latest SVN code, so I
have debugger fodder. This is a genuine regression from 6.2.5 indeed.

I'll debug this a bit.

-- 
Matthias Andree

[fetchmail-devel] Re: 6.2.6 fails where 6.2.5 was OK

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

On Fri, 18 Mar 2005, David Greaves wrote:

> I'm upgrading from 6.2.5 to 6.2.6 and I've encountered a possible bug 
> where 6.2.6 resends a CAPA challenge even when the server doesn't 
> understand it. The ISP is a major UK one.

Note that the 6.2.6 address given below...

> Matthias asked me to use the code from here to check another bug (this 
> was an embarrisingly long time ago)
> http://home.pages.de/~mandree/tmp/fetchmail-6.2.6.tar.bz2

...was test code, not the official 6.2.6 code.
Which is - we can share embarrassment here - still not released yet.

> I was going to hack on the code but thought I'd check first so...
> Is this a known issue? Is this code up-to-date?

The code is not up-to-date, and I don't see this problem when using my
version against a server that does not support CAPA.

May I ask you to try
http://home.pages.de/~mandree/tmp/fetchmail-6.2.5.991.tar.bz2
first and report here if your problem persists in 6.2.5.991?

That is newer code (2005-03-01) in spite of the lower version number
(the "6.2.6" snapshot is from 2004-11-10).

If the problem persists in that code, I'll have a closer look.

HTH,

-- 
Matthias Andree

[fetchmail-devel] 6.2.6 fails where 6.2.5 was OK

[David G. <da...@dg...>]

Hi

I'm upgrading from 6.2.5 to 6.2.6 and I've encountered a possible bug 
where 6.2.6 resends a CAPA challenge even when the server doesn't 
understand it. The ISP is a major UK one.

Matthias asked me to use the code from here to check another bug (this 
was an embarrisingly long time ago)
http://home.pages.de/~mandree/tmp/fetchmail-6.2.6.tar.bz2

I was going to hack on the code but thought I'd check first so...
Is this a known issue? Is this code up-to-date?

config:
1. OS: Linux RedHat 7.3 kernel 2.6.6
2. gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)
3. below
4. forwarding to lmtp listener on cyrus 2.2.3 (bounce goes to SMTP exim 
4.2)



here's a working 6.2.5 behaviour - notice that when it gets an ERR to 
the CAPA challenge it skips it (the CAPA) on the repoll:

fetchmail: 6.2.5 querying pop.freeserve.net (protocol POP3) at Fri 18 
Mar 2005 06:44:29 PM GMT: poll started
fetchmail: POP3< +OK connected to pop3 on 3212
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR unknown command
fetchmail: unknown command
fetchmail: Repoll immediately on 
da...@in...@pop.freeserve.com
fetchmail: POP3< +OK connected to pop3 on 3212
fetchmail: POP3> USER da...@in...
fetchmail: POP3< +OK name is a valid mailbox
fetchmail: POP3> PASS *
fetchmail: POP3< +OK user exist with that password
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 1 2518
1 message for da...@in... at pop.freeserve.net (2518 
octets).
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 2518
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK Message follows
reading message da...@in...@pop.freeserve.com:1 of 1 
(2518 octets)
About to rewrite Return-Path: <ka...@em...>
Rewritten version is Return-Path: <ka...@em...>

About to rewrite From: "Scotty Akers" <ka...@em...>
Rewritten version is From: "Scotty Akers" <ka...@em...>

About to rewrite To: da...@dg...
Rewritten version is To: da...@dg...

fetchmail: LMTP< 220 willow LMTP Cyrus v2.2.3 ready
fetchmail: LMTP> LHLO localhost
fetchmail: SMTP< 250-willow
fetchmail: SMTP< 250-8BITMIME
fetchmail: SMTP< 250-ENHANCEDSTATUSCODES
fetchmail: SMTP< 250-PIPELINING
fetchmail: SMTP< 250-SIZE
fetchmail: SMTP< 250-AUTH EXTERNAL
fetchmail: SMTP< 250 IGNOREQUOTA
fetchmail: forwarding to /var/imap/socket/lmtp
fetchmail: LMTP> MAIL FROM:<ka...@em...> SIZE=2518
fetchmail: LMTP< 250 2.1.0 ok
fetchmail: LMTP> RCPT TO:<da...@dg...>
fetchmail: LMTP< 250 2.1.5 ok
fetchmail: LMTP> DATA
fetchmail: LMTP< 354 go ahead
#***************************fetchmail: LMTP>. (EOM)
fetchmail: LMTP< 250 2.1.5 Ok
 flushed
fetchmail: POP3> DELE 1
fetchmail: POP3< +OK message deleted
fetchmail: POP3> QUIT
fetchmail: POP3< +OK
fetchmail: 6.2.5 querying pop.freeserve.net (protocol POP3) at Fri 18 
Mar 2005 06:44:48 PM GMT: poll completed



on 6.2.6, same config:
fetchmail: 6.2.6 querying pop.freeserve.net (protocol POP3) at Fri 18 
Mar 2005 06:42:42 PM GMT: poll started
fetchmail: POP3< +OK connected to pop3 on 3013
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR unknown command
fetchmail: unknown command
fetchmail: Repoll immediately on 
da...@in...@pop.freeserve.com
fetchmail: POP3< +OK connected to pop3 on 3212
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR unknown command
fetchmail: unknown command
fetchmail: Repoll immediately on 
da...@in...@pop.freeserve.com
fetchmail: POP3< +OK connected to pop3 on 3114
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR unknown command
fetchmail: unknown command
fetchmail: Repoll immediately on 
da...@in...@pop.freeserve.com
fetchmail: POP3< +OK connected to pop3 on 3013
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR unknown command
fetchmail: unknown command
fetchmail: Repoll immediately on 
da...@in...@pop.freeserve.com
fetchmail: POP3< +OK connected to pop3 on 3114
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR unknown command
fetchmail: unknown command
fetchmail: Repoll immediately on 
da...@in...@pop.freeserve.com


this hangs forever.

David


More config:

set syslog
set postmaster "da...@dg..."
set nobouncemail
set properties ""
set daemon 180
set idfile /var/run/fetchmail.ids

# tracepolls: Insert headers with pop3 acc info...


# fetchall: Sometimes messages are marked 'seen' if e.g. a fetchmail 
fails due
# to network dropping. This makes sure they're all retrieved:

# The ukfsn accounts
poll pop3.ukfsn.org with proto POP3 tracepolls
    user 'dgreaves' there with password 'xxxxxxxx' is da...@dg... 
here options fetchal
l lmtp smtp /var/imap/socket/lmtp expunge 30
    antispam 571 550 501 554
    user 'de...@at...' there with password 'xxxxxxxxxxx' 
is de...@dg...
here options fetchall lmtp smtp /var/imap/socket/lmtp expunge 30
    antispam 571 550 501 554
    user 'de...@dg...' there with password 'xxxxxxxxxxxx' is 
de...@dg... here opt
ions fetchall lmtp smtp /var/imap/socket/lmtp expunge 30
    antispam 571 550 501 554

# Old freeserve account - mainly spam now
poll pop.freeserve.net with proto POP3 tracepolls
    user 'da...@in...' there with password 'xxxxxxxxxx' 
is da...@dg... h
ere options fetchall lmtp smtp /var/imap/socket/lmtp expunge 30
    antispam 571 550 501 554
    user 'de...@in...' there with password 'xxxxxxxxx' 
is de...@dg...
 here options fetchall lmtp smtp /var/imap/socket/lmtp expunge 30
    antispam 571 550 501 554


# /usr/bin/fetchmail -V -v -v -f /etc/fetchmailrc
This is fetchmail release 6.2.6+NLS
Fallback MDA: (none)
Linux willow 2.6.6 #1 Wed Jun 2 12:15:21 BST 2004 i586 unknown
Taking options from command line and /etc/fetchmailrc
Poll interval is 180 seconds
Idfile is /var/run/fetchmail.ids
Progress messages will be logged via syslog
Fetchmail will forward misaddressed multidrop messages to 
da...@dg....
Fetchmail will direct error mail to the postmaster.
Options for retrieving from dgr...@po...:
  True name of server is pop3.ukfsn.org.
  This host will be queried when no host is specified.
  Password = "xxxxxxxxxx".
  Protocol is POP3 (using default port).
  All available authentication methods will be tried.
  Server nonresponse timeout is 300 seconds (default).
  Default mailbox selected.
  All messages will be retrieved (--all on).
  Fetched messages will not be kept on the server (--keep off).
  Old messages will not be flushed before message retrieval (--flush off).
  Rewrite of server-local addresses is enabled (--norewrite off).
  Carriage-return stripping is disabled (stripcr off).
  Carriage-return forcing is disabled (forcecr off).
  Interpretation of Content-Transfer-Encoding is enabled (pass8bits off).
  MIME decoding is disabled (mimedecode off).
  Idle after poll is disabled (idle off).
  Nonempty Status lines will be kept (dropstatus off)
  Delivered-To lines will be kept (dropdelivered off)
  No received-message limit (--fetchlimit 0).
  Fetch message size limit is 100 (--fetchsizelimit 100).
  Do binary search of UIDs during 9 out of 10 polls (--fastuidl 10).
  No SMTP message batch limit (--batchlimit 0).
  Deletion interval between expunges forced to 30 (--expunge 30).
  Messages will be LMTP-forwarded to: /var/imap/socket/lmtp
  Recognized listener spam block responses are: 571 550 501 554
  No pre-connection command.
  No post-connection command.
  Single-drop mode: 1 local name(s) recognized.
        da...@dg...
  No interface requirement specified.
  No monitor interface specified.
  No plugin command specified.
  No plugout command specified.
  No UIDs saved from this host.
  Poll trace information will be added to the Received header.
Options for retrieving from de...@at...@pop3.ukfsn.org:
  True name of server is pop3.ukfsn.org.
  This host will be queried when no host is specified.
  Password = "xxxxxxxx".
  Protocol is POP3 (using default port).
  All available authentication methods will be tried.
  Server nonresponse timeout is 300 seconds (default).
  Default mailbox selected.
  All messages will be retrieved (--all on).
  Fetched messages will not be kept on the server (--keep off).
  Old messages will not be flushed before message retrieval (--flush off).
  Rewrite of server-local addresses is enabled (--norewrite off).
  Carriage-return stripping is disabled (stripcr off).
  Carriage-return forcing is disabled (forcecr off).
  Interpretation of Content-Transfer-Encoding is enabled (pass8bits off).
  MIME decoding is disabled (mimedecode off).
  Idle after poll is disabled (idle off).
  Nonempty Status lines will be kept (dropstatus off)
  Delivered-To lines will be kept (dropdelivered off)
  No received-message limit (--fetchlimit 0).
  Fetch message size limit is 100 (--fetchsizelimit 100).
  Do binary search of UIDs during 9 out of 10 polls (--fastuidl 10).
  No SMTP message batch limit (--batchlimit 0).
  Deletion interval between expunges forced to 30 (--expunge 30).
  Messages will be LMTP-forwarded to: /var/imap/socket/lmtp
  Recognized listener spam block responses are: 571 550 501 554
  No pre-connection command.
  No post-connection command.
  Single-drop mode: 1 local name(s) recognized.
        de...@dg...
  No interface requirement specified.
  No monitor interface specified.
  No plugin command specified.
  No plugout command specified.
  No UIDs saved from this host.
  No poll trace information will be added to the Received header.
.
Options for retrieving from de...@dg...@pop3.ukfsn.org:
  True name of server is pop3.ukfsn.org.
  This host will be queried when no host is specified.
  Password = "xxxxxxxxx".
  Protocol is POP3 (using default port).
  All available authentication methods will be tried.
  Server nonresponse timeout is 300 seconds (default).
  Default mailbox selected.
  All messages will be retrieved (--all on).
  Fetched messages will not be kept on the server (--keep off).
  Old messages will not be flushed before message retrieval (--flush off).
  Rewrite of server-local addresses is enabled (--norewrite off).
  Carriage-return stripping is disabled (stripcr off).
  Carriage-return forcing is disabled (forcecr off).
  Interpretation of Content-Transfer-Encoding is enabled (pass8bits off).
  MIME decoding is disabled (mimedecode off).
  Idle after poll is disabled (idle off).
  Nonempty Status lines will be kept (dropstatus off)
  Delivered-To lines will be kept (dropdelivered off)
  No received-message limit (--fetchlimit 0).
  Fetch message size limit is 100 (--fetchsizelimit 100).
  Do binary search of UIDs during 9 out of 10 polls (--fastuidl 10).
  No SMTP message batch limit (--batchlimit 0).
  Deletion interval between expunges forced to 30 (--expunge 30).
  Messages will be LMTP-forwarded to: /var/imap/socket/lmtp
  Recognized listener spam block responses are: 571 550 501 554
  No pre-connection command.
  No post-connection command.
  Single-drop mode: 1 local name(s) recognized.
        de...@dg...
  No interface requirement specified.
  No monitor interface specified.
  No plugin command specified.
  No plugout command specified.
  No UIDs saved from this host.
  No poll trace information will be added to the Received header.
.
Options for retrieving from da...@in...@pop.freeserve.net:
  True name of server is pop.freeserve.net.
  This host will be queried when no host is specified.
  Password = "xxxxxxxx".
  Protocol is POP3 (using default port).
  All available authentication methods will be tried.
  Server nonresponse timeout is 300 seconds (default).
  Default mailbox selected.
  All messages will be retrieved (--all on).
  Fetched messages will not be kept on the server (--keep off).
  Old messages will not be flushed before message retrieval (--flush off).
  Rewrite of server-local addresses is enabled (--norewrite off).
  Carriage-return stripping is disabled (stripcr off).
  Carriage-return forcing is disabled (forcecr off).
  Interpretation of Content-Transfer-Encoding is enabled (pass8bits off).
  MIME decoding is disabled (mimedecode off).
  Idle after poll is disabled (idle off).
  Nonempty Status lines will be kept (dropstatus off)
  Delivered-To lines will be kept (dropdelivered off)
  No received-message limit (--fetchlimit 0).
  Fetch message size limit is 100 (--fetchsizelimit 100).
  Do binary search of UIDs during 9 out of 10 polls (--fastuidl 10).
  No SMTP message batch limit (--batchlimit 0).
  Deletion interval between expunges forced to 30 (--expunge 30).
  Messages will be LMTP-forwarded to: /var/imap/socket/lmtp
  Recognized listener spam block responses are: 571 550 501 554
  No pre-connection command.
  No post-connection command.
  Single-drop mode: 1 local name(s) recognized.
        da...@dg...
  No interface requirement specified.
  No monitor interface specified.
  No plugin command specified.
  No plugout command specified.
  No UIDs saved from this host.
  Poll trace information will be added to the Received header.
Options for retrieving from de...@in...@pop.freeserve.net:
  True name of server is pop.freeserve.net.
  This host will be queried when no host is specified.
  Password = "xxxxxxxxxx".
  Protocol is POP3 (using default port).
  All available authentication methods will be tried.
  Server nonresponse timeout is 300 seconds (default).
  Default mailbox selected.
  All messages will be retrieved (--all on).
  Fetched messages will not be kept on the server (--keep off).
  Old messages will not be flushed before message retrieval (--flush off).
  Rewrite of server-local addresses is enabled (--norewrite off).
  Carriage-return stripping is disabled (stripcr off).
  Carriage-return forcing is disabled (forcecr off).
  Interpretation of Content-Transfer-Encoding is enabled (pass8bits off).
  MIME decoding is disabled (mimedecode off).
  Idle after poll is disabled (idle off).
  Nonempty Status lines will be kept (dropstatus off)
  Delivered-To lines will be kept (dropdelivered off)
  No received-message limit (--fetchlimit 0).
  Fetch message size limit is 100 (--fetchsizelimit 100).
  Do binary search of UIDs during 9 out of 10 polls (--fastuidl 10).
  No SMTP message batch limit (--batchlimit 0).
  Deletion interval between expunges forced to 30 (--expunge 30).
  Messages will be LMTP-forwarded to: /var/imap/socket/lmtp
  Recognized listener spam block responses are: 571 550 501 554
  No pre-connection command.
  No post-connection command.
  Single-drop mode: 1 local name(s) recognized.
        de...@dg...
  No interface requirement specified.
  No monitor interface specified.
  No plugin command specified.
  No plugout command specified.
  No UIDs saved from this host.
  No poll trace information will be added to the Received header.
.

Re: [fetchmail-devel] lost UIDs

[Manfred W. <we...@ic...>]

Matthias Andree wrote:
> Manfred Weihs schrieb am 2005-03-06:
>>avoids possible problems with very long lists. Furthermore I slightly 
>>changed the interface and replaced the pointer to a pointer to the first 
>>list element by just a pointer to the first list element. I think, this 
> 
> 
> ...now is not the time for interface changes, as the next fetchmail
> release has been long overdue and intrusive changes should wait.

OK. I did not regard the change very intrusive and thought removing one 
level of dereferencing would make the code cleaner, but it is fine, as 
you commited it.

> Right. If you can live with a slower software that has less features in
> several areas, Charles Cazabon's getmail-4 has this feature.

Thanks for the hint. The last time I had a look at getmail there was 
some missing feature that prevented me from using it. But maybe it 
improved meanwhile. I will have a look at it.

Manfred Weihs