fetchmail-devel — Development related discussion

[fetchmail-devel] Downloading remote server certificate for a TLS session?

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

I was thinking about the recent thread that Anne Wilson started about
TLS certificate problems.  While there's a fairly easy way of getting
SSL certificates, there doesn't seem to be any way to use OpenSSL to
get a certificate from a TLS session.

As a generic solution it would be useful IMO if, at a high enough
verbosity (maybe -vvvv) fetchmail would display the certificate of the
remote TLS/SSL server *if that certificate can't be verified*.

Would that be reasonable, and easy to achieve?  If not is there any
other tool that can be used to get the certificate for a TLS secured
POP3 or IMAP server?

-- 
                 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] FAQ re-write

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

On 8/22/07, Matthias Andree <mat...@gm...> wrote:
>
> It is accessible, check <http://developer.berlios.de/wiki/?group_id=1824> -
> not much there yet except some internal development stuff that is outdated...

I'm having a look just now.

> There should be a HOWTO and the reference manual page. Currently it's all
> mixed into one large document; OTOH the problem is that two documents means
> doubled effort of keeping things up to date.

I don't see that there should be a huge amount of overlap between
these.  I assume the man page would cover the command line options and
the configuration file and the HowTo would largely consist of
configuration examples?

As for turning Wiki pages into HTML and/or PDF - neither look like
standard features of either the Berlios of PB Wikis.  Both conversions
however should be easy enough to automate/script (I've already written
some scripts to turn XML/HTML into PDF, based on HTMLDoc ISTR), though
I'm willing to be proven wrong :)

-- 
                 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] FAQ re-write

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

Rob MacGregor schrieb:

>> b. Berlios have a Wiki, but I'm a bit concerned about the packaging process
>> - I can't seem to find an export static pages version, but haven't got the
>> time now to check the site documentation for BerliOS.
> 
> If it's accessible to the general public I'll have a look later
> tonight (I should have an hour or so of time to myself :>).

It is accessible, check <http://developer.berlios.de/wiki/?group_id=1824> -
not much there yet except some internal development stuff that is outdated...

>> In the hope of further discussion on the "how"
> 
> And, once the dust settles on this, I'd like to discuss the "how" of
> re-working the small novel that is the man page.  That too I feel
> needs a split and re-write - every other man page has the command line
> options fairly close to the start, not a few dozen screens in.

There should be a HOWTO and the reference manual page. Currently it's all
mixed into one large document; OTOH the problem is that two documents means
doubled effort of keeping things up to date.

Best,
Matthias

Re: [fetchmail-devel] FAQ re-write

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

On 8/22/07, Matthias Andree <mat...@gm...> wrote:
>
> Your help will be very welcome.
>
> a. the split is a good idea, although I'm not sure about the "everything
> else" part and if I'd split 3) and 4) - these are often intertwined, and
> we'd have to make sure 6) doesn't contain parts that belong into 3 or 4.

As long as it's pointers I think that's ok.  I'm trying to think of
how people approach the "it's broken" thought process.

As for "everything else", I ran out of thoughts then :)

> b. Berlios have a Wiki, but I'm a bit concerned about the packaging process
> - I can't seem to find an export static pages version, but haven't got the
> time now to check the site documentation for BerliOS.

If it's accessible to the general public I'll have a look later
tonight (I should have an hour or so of time to myself :>).

> Generally speaking, any Wiki we use must be able to export the whole set of
> pages as static documents with working links and with marginal to zero
> effort - I want to ship the FAQ with the fetchmail package; pointing users
> to online sites for documentation is not something I'm eager to do - sooner
> or later someone will be trying to read that info while Berlios has some
> sort of downtime... oops. Can pbwiki.com export HTML and PDF?

I've no idea, but I'll have a look.  I do agree that making
assumptions about the future presence of a web site isn't good.

> In the hope of further discussion on the "how"

And, once the dust settles on this, I'd like to discuss the "how" of
re-working the small novel that is the man page.  That too I feel
needs a split and re-write - every other man page has the command line
options fairly close to the start, not a few dozen screens in.

-- 
                 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] FAQ re-write

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

Rob MacGregor schrieb:
> Recent events have persuaded me to get my proverbial finger out and
> look at re-writing the FAQ to be more "user friendly" (and a little
> more current).
> 
> With this in mind I'm soliciting feedback before I start :)
> 
> I'm considering splitting it into a number of pages, rather than the
> monolithic page it is currently.  My current plan is that these would
> cover (including the current areas):
> 
> 1) (G) General, with an initial paragraph emphasising the need to use
> the current version BEFORE asking for help with any problems
> 
> 2) (B and F) Build problems and configuration file problems
> 
> 3) (S and I) Problems downloading email
> 
> 4) (T, D and M)) Problems passing email to your local mail system
> 
> 5) (K) Proxies and Security (including SSL and SOCKS)
> 
> 6) (R and H) Runtime problems
> 
> 7) (C and M) Configuration problems and examples
> 
> 8) (X and O) Everything else
> 
> Actually, I'd really like to get this into a Wiki because it means
> that it's easier to work on it as I get time, plus it means that
> others can easily add to/correct it as required.  I don't know if
> Berlios has such functionality though (but I do know that pbwiki.com
> is free).
> 
> Thoughts?

Your help will be very welcome.

a. the split is a good idea, although I'm not sure about the "everything
else" part and if I'd split 3) and 4) - these are often intertwined, and
we'd have to make sure 6) doesn't contain parts that belong into 3 or 4.

b. Berlios have a Wiki, but I'm a bit concerned about the packaging process
- I can't seem to find an export static pages version, but haven't got the
time now to check the site documentation for BerliOS.

Generally speaking, any Wiki we use must be able to export the whole set of
pages as static documents with working links and with marginal to zero
effort - I want to ship the FAQ with the fetchmail package; pointing users
to online sites for documentation is not something I'm eager to do - sooner
or later someone will be trying to read that info while Berlios has some
sort of downtime... oops. Can pbwiki.com export HTML and PDF?

In the hope of further discussion on the "how"

Best regards
Matthias

[fetchmail-devel] [Bug #11797] imap_mark_seen doesn't consider expunged messages

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

Bug #11797, was updated on 2007-Aug-19 01:53
Here is a current snapshot of the bug.

Project: Community Fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: cqrs
Assigned to : none
Summary: imap_mark_seen doesn't consider expunged messages

Details: There seems to be a bug in the imap_mark_seen function -- it doesn't take
expunged messages into account.

Here is an example. First, .fetchmailrc :

======================================================================
poll XXXXXXXXXX
  protocol IMAP
  plugin "ssh %h /usr/sbin/imapd"
  auth ssh
  mda "formail >> fetched.mail"
  keep
  flush
======================================================================

Suppose there are two messages on the server -- one old (seen) and one
new. With the config above fetchmail should expunge the first message,
then fetch the second message and mark it seen. In fact fetchmail cannot
mark the second message seen because of the wrong number.
Output of "fetchmail -v":

======================================================================
fetchmail: 6.3.8 querying XXXXXXXXXX (protocol IMAP) at Thu Aug  9 20:03:53 2007: poll started
fetchmail: running ssh %h /usr/sbin/imapd (host XXXXXXXXXX service imap)
fetchmail: IMAP< * PREAUTH [CAPABILITY IMAP4REV1 LITERAL+ IDLE NAMESPACE MAILBOX-REFERRALS BINARY UNSELECT SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] Pre-authenticated user YYYYYYYYYY XXXXXXXXXX IMAP4rev1 2004.352 at Thu, 9 Aug 2007 20:05:13 +0400 (MSD)
fetchmail: IMAP> A0001 CAPABILITY
fetchmail: IMAP< * CAPABILITY IMAP4REV1 LITERAL+ IDLE NAMESPACE MAILBOX-REFERRALS BINARY UNSELECT SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND SASL-IR LOGIN-REFERRALS AUTH=LOGIN
fetchmail: IMAP< A0001 OK CAPABILITY completed
fetchmail: IMAP> A0002 SELECT "INBOX"
fetchmail: IMAP< * 2 EXISTS
fetchmail: IMAP< * 0 RECENT
fetchmail: IMAP< * OK [UIDVALIDITY 1104692132] UID validity status
fetchmail: IMAP< * OK [UIDNEXT 147861] Predicted next UID
fetchmail: IMAP< * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
fetchmail: IMAP< * OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft \Seen)] Permanent flags
fetchmail: IMAP< * OK [UNSEEN 2] first unseen message in /var/spool/mail/YYYYYYYYYY
fetchmail: IMAP< A0002 OK [READ-WRITE] SELECT completed
fetchmail: IMAP> A0003 SEARCH UNSEEN NOT DELETED
fetchmail: IMAP< * SEARCH 2
fetchmail: IMAP< A0003 OK SEARCH completed
2 messages (1 seen) for YYYYYYYYYY at XXXXXXXXXX.
skipping message YYYYYYYYYY@XXXXXXXXXX:1 flushed
fetchmail: IMAP> A0004 STORE 1 +FLAGS (\Seen \Deleted)
fetchmail: IMAP< * 1 FETCH (FLAGS (\Seen \Deleted))
fetchmail: IMAP< A0004 OK STORE completed
fetchmail: IMAP> A0005 EXPUNGE
fetchmail: IMAP< * 1 EXPUNGE
fetchmail: IMAP< * 1 EXISTS
fetchmail: IMAP< * 0 RECENT
fetchmail: IMAP< A0005 OK Expunged 1 messages
fetchmail: IMAP> A0006 FETCH 1 RFC822.SIZE
fetchmail: IMAP< * 1 FETCH (RFC822.SIZE 939)
fetchmail: IMAP< A0006 OK FETCH completed
fetchmail: IMAP> A0007 FETCH 1 RFC822.HEADER
fetchmail: IMAP< * 1 FETCH (RFC822.HEADER {933}
reading message YYYYYYYYYY@XXXXXXXXXX:2 of 2 (933 header octets)
fetchmail: IMAP< )
fetchmail: IMAP< A0007 OK FETCH completed
fetchmail: IMAP> A0008 FETCH 1 BODY.PEEK[TEXT]
fetchmail: IMAP< * 1 FETCH (BODY[TEXT] {6}
 (6 body octets)fetchmail: IMAP< )
fetchmail: IMAP< A0008 OK FETCH completed
 not flushed
fetchmail: IMAP> A0009 STORE 2 +FLAGS (\Seen)
fetchmail: IMAP< A0009 BAD Bogus sequence in STORE: Sequence out of range
fetchmail: IMAP> A0010 LOGOUT
fetchmail: IMAP< * BYE XXXXXXXXXX IMAP4rev1 server terminating connection
fetchmail: IMAP< A0010 OK LOGOUT completed
fetchmail: client/server synchronization error while fetching from YYYYYYYYYY@XXXXXXXXXX
fetchmail: 6.3.8 querying XXXXXXXXXX (protocol IMAP) at Thu Aug  9 20:03:58 2007: poll completed
fetchmail: Query status=7 (ERROR)
fetchmail: normal termination, status 7
======================================================================

When there are more messages on the server wrong messages would be marked
seen before fetchmail fail. These messages will be lost on the next run.
Even worse, some IMAP servers happily allow wrong message numbers in STORE
command. In such cases a user will not even see any error message.

Adding "expunge 0" to config mitigates the problem. And the following 
patch seems to solve it:

======================================================================
diff -urN fetchmail-6.3.8.orig/imap.c fetchmail-6.3.8/imap.c
--- fetchmail-6.3.8.orig/imap.c 2006-12-16 03:34:38.000000000 +0300
+++ fetchmail-6.3.8/imap.c      2007-08-08 15:37:10.000000000 +0400
@@ -1239,6 +1239,9 @@
 static int imap_mark_seen(int sock, struct query *ctl, int number)
 /* mark the given message as seen */
 {
+    /* expunges change the fetch numbers */
+    number -= expunged;
+
     (void)ctl;
     return(gen_transact(sock,
        imap_version == IMAP4
======================================================================

Tested on fetchmail 6.3.8.

P.S. Thanks for the great program.


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

[fetchmail-devel] FAQ re-write

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

Recent events have persuaded me to get my proverbial finger out and
look at re-writing the FAQ to be more "user friendly" (and a little
more current).

With this in mind I'm soliciting feedback before I start :)

I'm considering splitting it into a number of pages, rather than the
monolithic page it is currently.  My current plan is that these would
cover (including the current areas):

1) (G) General, with an initial paragraph emphasising the need to use
the current version BEFORE asking for help with any problems

2) (B and F) Build problems and configuration file problems

3) (S and I) Problems downloading email

4) (T, D and M)) Problems passing email to your local mail system

5) (K) Proxies and Security (including SSL and SOCKS)

6) (R and H) Runtime problems

7) (C and M) Configuration problems and examples

8) (X and O) Everything else

Actually, I'd really like to get this into a Wiki because it means
that it's easier to work on it as I get time, plus it means that
others can easily add to/correct it as required.  I don't know if
Berlios has such functionality though (but I do know that pbwiki.com
is free).

Thoughts?

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

[fetchmail-devel] [Bug #11576] fetchmail does not report SSL negotiation errors properly

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

Bug #11576, was updated on 2007-Jul-17 14:34
Here is a current snapshot of the bug.

Project: Community Fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: psusi
Assigned to : none
Summary: fetchmail does not report SSL negotiation errors properly

Details: Matthias Andree asked me to file this bug report after our discussion on the fetchmail-users list in the thread titled "Invalid SSL certificate".  


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

[fetchmail-devel] [Feature #3474] IDLE-support for multiple folders

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

Feature Request #3474, was updated on 2007-Jun-06 00:09
You can respond by visiting: 
http://developer.berlios.de/feature/?func=detailfeature&feature_id=3474&group_id=1824

Category: None
Status: Open
Priority: 5
Summary: IDLE-support for multiple folders

By: secure
Date: 2007-Jun-06 00:09

Message:
Logged In: YES 
user_id=38600
Browser: Opera/9.10 (X11; Linux x86_64; U; en)

I'd like to see IDLE-support for multiple folders in fetchmail, as this is a 
kinda stupid restriction -- one would need to start fetchmail several 
times to fetch multiple folders efficiently.

You could implement this using fork() or threads (I'd prefer fork() in this 
case)

----------------------------------------------------------------------
You can respond by visiting: 
http://developer.berlios.de/feature/?func=detailfeature&feature_id=3474&group_id=1824

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

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

>    ftp://ftp.unex.es/pub/gnu-i18n/po/maint/fetchmail/vi.po
>    http://translation.sf.net/maint/fetchmail/vi.po

This file has already been sent to you separately on 2007-05-28,
as a MIME invoice unpacking the file `fetchmail-6.3.8.vi.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] [Bug #10972] Fetchmail refetches big messages repeatedly

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

Bug #10972, was updated on 2007-May-03 00:51
Here is a current snapshot of the bug.

Project: Community Fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: bviktor
Assigned to : none
Summary: Fetchmail refetches big messages repeatedly

Details: If downloading a message takes more time than the configured timeout value, fetchmail does not mark it as read, or delete it from the server, even if it has been delivered correctly. This makes it refetch the same message repeatedly (like a mail loop).

I'm using fetchmail on a Debian "etch" server with the following configuration:

fetchmail -V:
"This is fetchmail release 6.3.6+NTLM+SDPS+SSL+NLS."

fetchmailrc:

set syslog
set daemon 120

defaults
    timeout 60, fetchall

poll "mail.web-server.hu" protocol POP3: user "***" there with password "***" is "***" here
fetchall nokeep ssl;

The server I'm connecting to is a bit broken SSL-wise: 

Server certificate verification error: self signed certificate
Server CommonName mismatch: localhost != mail.web-server.hu



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

[fetchmail-devel] [Bug #10957] mailbox emptied even though I used --keep

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

Bug #10957, was updated on 2007-Apr-30 17:03
Here is a current snapshot of the bug.

Project: Community Fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: muir
Assigned to : none
Summary: mailbox emptied even though I used --keep

Details: The following emptied out my email archive:

fetchmail --verbose --keep --all --proto IMAP --user mu...@ma... \
        --folder Archive \
        --mda '/usr/local/ii/bin/build-corpus --ham --username=mu...@id... --queueonly' \
        mail.day.org

From the documentation, I thought that using --keep
would preserve my messages on the server.

The server, by the way, is Zimbra.

-Dave

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

Re: [fetchmail-devel] [PATCH] fetchmail.man mentions wrong options

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

Hi,
* Matthias Andree <mat...@gm...> [2007-04-29 22:10]:
[...] 
> >  This option, even if the argument is the empty string, will also
> >  suppress the diagnostic 'SERVER: opportunistic upgrade to TLS.' message
> 
> The match is case insensitive, so no need to hack the manpage.
> I can't reproduce this in 6.3.8 either, so no action required upstream.

Damn me, it's strcasecmp. Mhm, then it's strange.
kind regards
Nico
-- 
Nico Golde - http://ngolde.de - ni...@ja... - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.

Re: [fetchmail-devel] [PATCH] fetchmail.man mentions wrong options

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

Nico Golde schrieb:
> Hi,
> attached patch fixes Debian bug
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421446
> Kind regards
> Nico

Does it?

> --- fetchmail.man	2007-04-08 14:52:42.000000000 +0200
> +++ fetchmail.man.new	2007-04-29 16:59:30.000000000 +0200
> @@ -408,10 +408,10 @@
>  .TP
>  .B \-\-sslproto <name>
>  (Keyword: sslproto)
> -Forces an SSL or TLS protocol. Possible values are '\fBSSL2\fR',
> -\&'\fBSSL3\fR', '\fBSSL23\fR', and '\fBTLS1\fR'. Try this if the default
> +Forces an SSL or TLS protocol. Possible values are '\fBssl2\fR',
> +\&'\fBssl3\fR', '\fBssl23\fR', and '\fBtls1\fR'. Try this if the default
>  handshake does not work for your server. Use this option with
> -'\fBTLS1\fR' to enforce a TLS connection. To defeat opportunistic TLSv1
> +'\fBtls1\fR' to enforce a TLS connection. To defeat opportunistic TLSv1
>  negotiation when the server advertises STARTTLS or STLS, use \fB''\fR.
>  This option, even if the argument is the empty string, will also
>  suppress the diagnostic 'SERVER: opportunistic upgrade to TLS.' message

The match is case insensitive, so no need to hack the manpage.
I can't reproduce this in 6.3.8 either, so no action required upstream.

-- 
Matthias Andree

[fetchmail-devel] [PATCH] fetchmail.man mentions wrong options

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

Hi,
attached patch fixes Debian bug
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421446
Kind regards
Nico

-- 
Nico Golde - http://ngolde.de - ni...@ja... - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.

[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

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

This file has already been sent to you separately on 2007-04-27,
as a MIME invoice unpacking the file `fetchmail-6.3.8.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.3.8.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.8.pot
>    http://translation.sf.net/domains/POT/fetchmail-6.3.8.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/fetchmail/fetchmail-6.3.8.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] [fetchmail-users] Fetchmail Socket error on asatellite connection

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

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

> On 4/13/07, Matthias Andree <mat...@gm...> wrote:
>> Rob MacGregor schrieb:
>>
>> You're most welcome on this task - I haven't kept a close eye on what
>> part of the information is outdated and what not, and I've so far only
>> removed the most obvious stale stuff.
>
> Strange, nobody likes doing documentation :)

At least not if it's documentation pertaining to code due to change anyways :)

> Some form of diagnosis tool(s) wouldn't be a bad idea either, though
> I've no idea what form that would take.  Enough to confirm that the
> basic networking part is functional and that fetchmail can (or cannot)
> talk to the remote server.

Python script perhaps, Python is widespread today.

> Beyond that, if people won't/don't/can't do what they're asked to do
> then there's not really much point in continuing to flog the
> proverbial horse.  In this case the OP did at least provide the
> directly fetchmail related info, just nothing about his (unusual)
> comms setup.

I wouldn't even call it unusual comms setup without knowing the details,
but that it gives him headaches while ADSL doesn't is reason for his
concern.

Anyways, the valid point is that just "socket error" isn't a very
detailed report.

-- 
Matthias Andree

Re: [fetchmail-devel] [fetchmail-users] Fetchmail Socket error on asatellite connection

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

On 4/13/07, Matthias Andree <mat...@gm...> wrote:
> Rob MacGregor schrieb:
>
> You're most welcome on this task - I haven't kept a close eye on what
> part of the information is outdated and what not, and I've so far only
> removed the most obvious stale stuff.

Strange, nobody likes doing documentation :)

> I'd like your view on this: Should we provide a short (1 - 2 pages if
> printed) document on how to get support efficiently" - perhaps along
> DJB's[1] lines of 'what did you do, what did the computer do, what did
> you expect' - ESR's smart questions is right, but long-winding for
> someone who is on the verge of panicking.

I think that, and a simple flow (diagram?) showing how it fits
together so people can more easily understand.  I suspect part of the
"problem" is that less technical people are using *nix these days,
meaning that previous assumptions are no longer valid (and that's in
general, not specific to fetchmail by any means).

Some form of diagnosis tool(s) wouldn't be a bad idea either, though
I've no idea what form that would take.  Enough to confirm that the
basic networking part is functional and that fetchmail can (or cannot)
talk to the remote server.

Well, I've got a few days off work now so II'll give this some more thought.

> I also think if you want to take a stab at splitting the FAQ, we can
> arrange for Subversion access with Graham - let's take this part
> off-list or to -devel however.

Devel probably makes most sense and I am subscribed there (CCd for
this mail).  That way others can throw their 0.02$CURRENCY in :)

> You'll see I worded carefully to give my *personal* view, without any
> hints towards what my right hand of the support should do, and I'd say
> do what pleases *you* most, unless it's treating people without dignity.

Well, given that bugs will only be fixed in the current stable
version, there's little point in trying to support older versions
(which, IMO, is the right approach).

Beyond that, if people won't/don't/can't do what they're asked to do
then there's not really much point in continuing to flog the
proverbial horse.  In this case the OP did at least provide the
directly fetchmail related info, just nothing about his (unusual)
comms setup.

-- 
                 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] [Bug #10841] fetchmail (all versions incl 6.3.8) hangs on certain mails.

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

Quoting from ad...@be...'s mail on Tue, Apr 10, 2007:
> Summary: fetchmail (all versions incl 6.3.8) hangs on certain mails.

...

> fetchmail: SMTP> DATA
> fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself
> #
> fetchmail: IMAP< )
> fetchmail: IMAP< A0007 OK FETCH completed
> fetchmail: IMAP> A0008 FETCH 1 BODY.PEEK[TEXT]
> fetchmail: IMAP< * 1 FETCH (BODY[TEXT] {51647}
>  (51647 body octets)*******************************.***************************.********************************.************************************.***********************************.****************.*****************.****************.****************.****************.**********************.********************.*****************************.****************.*****************.****************.*****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.*****************.*************
>  ***.***********
> fetchmail: timeout after 30 seconds waiting for server xpop.
> fetchmail: socket error while fetching from xxx@xpop
> fetchmail: 6.3.8 querying xpop (protocol IMAP) at Tue, 10 Apr 2007 10:21:22 +0200 (MET DST): poll completed
> fetchmail: Query status=2 (SOCKET)
> fetchmail: normal termination, status 2

Please send similar logs for a few normal mails.

-- 
Sunil Shetye.

[fetchmail-devel] [Bug #10841] fetchmail (all versions incl 6.3.8) hangs on certain mails.

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

Bug #10841, was updated on 2007-Apr-10 04:16
Here is a current snapshot of the bug.

Project: Community Fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: acni
Assigned to : none
Summary: fetchmail (all versions incl 6.3.8) hangs on certain mails.

Details: 
About 2-3 times a year, fetchmail hangs while fetching certain
messages (mostly probably misformatted spam or bounces),
preventing ever fetching the rest of the mail. This happend
again today. Like always, I upgraded (to fetchmail-6.3.8)
but the problem persists.

Reproducing seems difficult because I can not artificially
create that condition on the server. But when it happens
with a certain email, fetchmail will reproducably fail whatever
you do.
Other mail clients have no difficulty (not even reading the
possibly faulty message) - neither should fetchmail.

Fetchmail should be more tolerant accepting misformatted
messages (or maybe resulting protocol deviations?)
from the server, because if one of these mails is present,
also all email after the faulty mail can never be fetched.
Another client has then to be used (even old Versions of
Netscape 4.7 etc work), to remove the offending message,
but access with this other mail client then messes up the
"Seen" flags etc, so that after that "fetchmail --all" has to
be used and redundant mail deleted. Most inconvenient,
and very annoying in daemon mode (one such message
blocks further delivery of all mails, until returning from
holidays and fixing the problem manually, as outlined above).

It is independent of the timeout used (30 seconds used below,
but even 1 hr doesn't change anything).

The problem looks like this:
 
% fetchmail
Enter password for xxx@xpop: 
8 messages for I0016733 at xpop (folder Inbox).
reading message I00...@gg...:1 of 8 (568 header octets) (51604 body octets)..................................................fetchmail: timeout after 30 seconds.
fetchmail: socket error while fetching from xxx@xpop
fetchmail: Query status=2 (SOCKET)

or, with "verbose" on:

... Recipient ok
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself
#
fetchmail: IMAP< )
fetchmail: IMAP< A0007 OK FETCH completed
fetchmail: IMAP> A0008 FETCH 1 BODY.PEEK[TEXT]
fetchmail: IMAP< * 1 FETCH (BODY[TEXT] {51647}
 (51647 body octets)*******************************.***************************.********************************.************************************.***********************************.****************.*****************.****************.****************.****************.**********************.********************.*****************************.****************.*****************.****************.*****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.****************.*****************.*****************.****************.***********
fetchmail: timeout after 30 seconds waiting for server xpop.
fetchmail: socket error while fetching from xxx@xpop
fetchmail: 6.3.8 querying xpop (protocol IMAP) at Tue, 10 Apr 2007 10:21:22 +0200 (MET DST): poll completed
fetchmail: Query status=2 (SOCKET)
fetchmail: normal termination, status 2



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

[fetchmail-devel] fetchmail 6.3.8 security fix release

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

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

Greetings,

I am announcing the release of fetchmail 6.3.8. This new stable version
of fetchmail strengthens the APOP validator to make the
man-in-the-middle attack to be presented as CVE-2007-1558 more
difficult. It also fixes a regression from the 6.3.6 security patches
and further long-standing bugs.

Note that 6.3.8 is the last planned release on the 6.3 branch, further
planned fetchmail releases will take some time to appear and contain
larger changes.

The software is available from:
<http://developer.berlios.de/project/showfiles.php?group_id=1824>

The fetchmail home pages are:
<http://www.fetchmail.info/>  or  <http://fetchmail.berlios.de/>

These are the relevant changes in 6.3.8 since 6.3.7;
unless otherwise noted, changes to this release were made by Matthias Andree:

# ADVANCE WARNING OF FEATURES TO BE REMOVED OR CHANGED IN FUTURE VERSIONS
(There are no plans to remove these features from a 6.3.X release, but they may
be removed from a 6.4.0 or newer release.)
* The MX and host alias DNS lookups that fetchmail performs in multidrop mode
  are based on assumptions that are rarely met in practice, somewhat defective,
  deprecated and may be removed from a future fetchmail version.  They have
  never supported IPv6 (including IPv6-mapped IPv4).
  Non-DNS based alias keywords such as "aka" will remain in fetchmail.
* The monitor and interface options may be removed from a future fetchmail
  version as they are not reasonably portable.
* POP2 is obsolete, support will be removed from a future fetchmail version.
* RPOP is obsolete, support will be removed from a future fetchmail release.
* --sslcertck will become a default setting in a future fetchmail version.
* The multidrop To/Cc guessing code along with the fragile duplicate suppressor
  is deprecated and may be removed from a future release.
* The "envelope Received" option may be removed from a future release, because
  the Received header was never meant to be machine-readable, the format varies
  widely, and various other differences in behavior make parsing Received an
  unreliable undertaking. The envelope option as such will remain though, in
  order to support Delivered-To, X-Envelope-To, X-Original-To and similar.
  See also <http://home.pages.de/~mandree/mail/multidrop>.
* The --enable-fallback (fall back to MDA if MTA unavailable) will be removed
  from a future fetchmail release, because it makes fetchmail's behavior
  inconsistent and confusing.
* The "protocol auto" default inside fetchmail may be removed from a future
  fetchmail release. Explicit configuration of the protocol is recommended.
* Kerberos IV support may be removed from a future fetchmail release.
* SIGHUP wakeup support may be removed from a future fetchmail release and
  cause fetchmail to terminate - it was broken for many years.
* Support for operating systems that are not sufficiently POSIX compliant may be
  removed or operation on such systems may be suboptimal for future releases.

# SECURITY STRENGTHENING:
* Make the APOP challenge parser more distrustful and have it reject challenges
  that do not conform to RFC-822 msg-id format, in the hope to make mounting
  man-in-the-middle attacks (MITM) against APOP a bit more difficult.
  (CVE-2007-1558, reported by Gaëtan Leurent, published 2007-04-02 on Bugtraq)

  APOP is claimed insecure by Gaëtan Leurent for MITM scenarios for typical
  setups: based on MD5 collisions, it is purportedly possible to recover the
  first three characters of the shared secret (password), which would then make
  recovery of the shared secret a matter of hours or minutes; this would then
  enable the attacker to impersonate the client vis-à-vis the server.

  For further details, check
  * Gaëtan Leurent, "Message Freedom in MD4 and MD5 Collisions: Application
  to APOP", Fast Software Encryption 2007, Luxembourg. (Proceedings to appear in
  Springer's Lecture Notes on Computer Science.)
  * The mailing list discussion thread at
  <http://lists.berlios.de/pipermail/fetchmail-devel/2007-March/000887.html>

# BUG FIXES:
* Fix pluralization of oversized-message warning mails.
* Fix manual page: --sslcheck -> --sslcertck, and do not set trailing 
  "recommended:" in bold. Fixes Debian Bug #413059, reported by Rafal Czlonka.
* Repoll immediately if a protocol error happens during the authentication 
  attempt after a failed opportunistic TLS upgrade.
  Fixes comment #9 in Gentoo Bug #163782, reported by Takuto Matsuu.
* Fix rendering of the "24 - 26, 28, 29" paragraph in the exit codes section. 
  Reported by Nico Golde.
* If SOCKS support was compiled in, add 'socks' to the feature_options Python
  list emitted in --configdump. Reported by Rob MacGregor.
* Do not crash with a null pointer dereference when opening the BSMTP file 
  fails. Improve error checking and reporting. Reported by Reto Schüttel,
  Debian Bug#416625. Fix based on a patch by Nico Golde.
* Make BSMTP output actually work, it would persistently fail with SOCKET error
  after writing the first header. Bug independently found and reported in
  excellent detail by Reto Schüttel, Debian Bug#416812.

# DOCUMENTATION:
* Add fetchmail-SA-2007-01.txt
* Extend --mda documentation, discourage use of qmail-inject.
  Based on a patch by Rob MacGregor.
* Document SOCKS configuration facility (SOCKS_CONF environment variable).
  Thanks to Jochen Hayek, Michael Shuldman and Rob MacGregor.
* Use envelope option in multidrop example. Patch by Rob MacGregor.
* Document expected Received: line format when parsing for envelope addressees.
* Stripped option documentation from sample.rcfile, since this is bound to go
  out of synch with the manual page, which is the only reference on options.
* Mention that --limit default is 0 bytes, which is special for "no limit".
* Corrected Robert M. Funk's name that I misspelled. My sincere apologies
  -- Matthias Andree.

# CONTRIB:
* Add delete-later and delete-later.README, a script and documentation for
  a MySQL/Tcl-based client-side "delete-after" feature.
  Kindly donated by Yoo GmbH, Großvoigtsberg, Germany (Carsten Ralle).

# KNOWN BUGS AND WORKAROUNDS:
  (this section floats upwards through the NEWS file so it stays with the
  current release information)
* fetchmail does not handle messages without Message-ID header well
  (See sourceforge.net bug #780933)
* BSMTP is mostly untested and errors can cause corrupt output.
* Sun Workshop 6 (SPARC) is known to miscompile the configuration file lexer in
  64-bit mode.  Either compile 32-bit code or use GCC to compile 64-bit
  fetchmail.  Note that fetchmail doesn't take advantage of 64-bit code,
  so compiling 32-bit SPARC code should not cause any difficulties.
* fetchmail does not track pending deletes over crashes
* the command line interface is a bit narrow-minded sometimes, for instance,
  fetchmail -s doesn't work with a running daemon
* some of the logging output is not very helpful
* some of the documentation is still not up to date

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

iD8DBQFGFq68vmGDOQUufZURAidjAKCG9+TAjmMz7l/9KWFROKBqhyBLPgCg9hbo
KAMMlF17J1XRbB/rGR9uiSA=
=orbA
-----END PGP SIGNATURE-----

[fetchmail-devel] HEADS UP: fetchmail 6.3 release plans (was: fetchmail 6.3.8-rc3 release candidate)

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

I wrote:

> I have uploaded the third fetchmail 6.3.8 release candidate to the usual
> download location: <http://home.pages.de/~mandree/fetchmail/>.

NOTE that fetchmail 6.3.8 is the last planned fetchmail 6.3.X release.
I plan to put the 6.3 branch on hold and only fix severe bugs
afterwards, so as to free resources for spawning a new branch.

The new branch will make some more radical changes to the code, remove
legacy code, misguided attempts, and clean up the mess - perhaps we'll
see a few features as well.

So, if you want your bug to be fixed before the next release, it is very
important that you test 6.3.8-rc3 and report issues quickly, I plan to
release 6.3.8 in 8 - 10 days time.


I don't expect the new branch to make headway quickly though, I'm busy
with real-time work, the only active fetchmail developer at this
time, and living in the northern hemisphere means spring and summer are
approaching, so I'll probably spend less time on coding anyways...

-- 
Matthias Andree

[fetchmail-devel] fetchmail 6.3.8-rc3 release candidate

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

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

Greetings,

I have uploaded the third fetchmail 6.3.8 release candidate to the usual
download location: <http://home.pages.de/~mandree/fetchmail/>.

This became necessary after long-standing BSMTP bugs had been reported
after -rc2.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Changes in 6.3.8-rc3 since -rc2 (2007-03-31):

* If SOCKS support was compiled in, add 'socks' to the feature_options Python
  list emitted in --configdump. Reported by Rob MacGregor.
* Do not crash with a null pointer dereference when opening the BSMTP file 
  fails. Improve error checking and reporting. Reported by Reto Schüttel,
  Debian Bug#416625. Fix based on a patch by Nico Golde.
* Make BSMTP output actually work, it would persistently fail with SOCKET error
  after writing the first header.
* Corrected Robert M. Funk's name that I misspelled. My sincere apologies
  -- Matthias Andree.
* BSMTP is mostly untested and errors can cause corrupt output.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

WARNING: This message sets the Reply-To: header.
When replying to me personally, you need to edit the To: header!

Thank you.

Happy fetching,
Matthias Andree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFGDq9bvmGDOQUufZURAqQmAJ46jJBsnO/7fjarFOKZNfGOGrA/YQCg7TrJ
yrPNxFS9JkO39I/qPgz6aBo=
=RuQW
-----END PGP SIGNATURE-----