fetchmail-devel — Development related discussion

Re: [fetchmail-devel] RFC: support --smtphost for bounces

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

Quoting from Matthias Andree's mail on Mon, Feb 19, 2007:
> how about the attached patch to fix the "bounces are always
> SMTP-injected to localhost without regard to the --smtphost"?
> <http://bugs.debian.org/150137>
> 
> It's not perfect, and I don't know how to handle cases where --smtphost
> contains LMTP hosts exclusively or is switched to LMTP by --lmtp -
> suggestions?

A lot more work will be required for this.

Here I am assuming that smtphost is not localhost and requires
authentication for relaying the bounce message. The code currently
does not do that because localhost (by default) allows relaying of the
bounce message without authentication.

For using smtphost as a relay server for the bounce message, fetchmail
will have to authenticate using esmtpname. For that, fetchmail will
have to send EHLO, save the response, and parse it. For that, separate
structure will have to be maintained per smtp connection. All the smtp
variables which are currently global/static will have to be part of
that structure.

There will also be a compatibility problem if the user has not
specified any esmtpname. This is not a problem for the incoming mail
as the mail is (presumably) being delivered locally on the smtphost.
However, for the bounce message, authentication is a must as the
smtphost is now going to act as a relay server. So, smtphost should be
automatically used only if the user has specified an esmtpname.

-- 
Sunil Shetye.

[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.7.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.7.pot
>    http://translation.sf.net/domains/POT/fetchmail-6.3.7.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.7.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...

[fetchmail-devel] RFC: support --smtphost for bounces

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

Hi,

how about the attached patch to fix the "bounces are always
SMTP-injected to localhost without regard to the --smtphost"?
<http://bugs.debian.org/150137>

It's not perfect, and I don't know how to handle cases where --smtphost
contains LMTP hosts exclusively or is switched to LMTP by --lmtp -
suggestions?

Thanks,

-- 
Matthias Andree

[fetchmail-devel] fetchmail 6.3.7 regression fixes release

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

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

Greetings,

I am announcing the release of fetchmail 6.3.7.

This new stable version of fetchmail fixes two regressions that were
recently introduced into the security fix release 6.3.6, see below for
details.

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

The fetchmail home page is:
<http://www.fetchmail.info/>  or  <http://fetchmail.berlios.de/>

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

# FIXES FOR REGRESSIONS IN 6.3.6
* Fix KPOP. Patch by Miloslav Trmac.
* Fix repoll when server disconnects after opportunistic TLS failed for POP3.
  Berlios Bug #10133 = Gentoo Bug #163782 reported by Andrej Kacian.

# TRANSLATION UPDATES
* Japanese (Takeshi Hamasaki), Polish (Jakub Bogusz)

# CHANGES
* Consider getaddrinfo() on Darwin 9 (Mac OS X 10.5 "Leopard") thread-safe.
  Reported by Uli Zappe.

Best regards

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

iD8DBQFF2JDCvmGDOQUufZURAnXhAJ9isKNGpjQX8G6HTB6CvxjQfHIRmQCeLtsR
WBIHVcRoyddo4tL5fAVZoEY=
=7x5d
-----END PGP SIGNATURE-----

Re: [fetchmail-devel] [PATCH] Fix KPOP

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

Matthias Andree napsal(a):
> On Wed, 31 Jan 2007, Miloslav Trmac wrote:
>> The only KPOP server I could find is cyrus-imapd, which completely
>> ignores the password submitted with PASS.  I wasn't able to find any
>> specification of KPOP, so I don't know for sure.  I can imagine a server
>> that requires both Kerberos authentication and the correct password.
> Does KPOP still work with the attached patch? (Apply on top of your
> patch.)
I'm sorry about the delay.  fetchmail-6.3.7-rc1 works with cyrus-imapd
correctly.
	Mirek

[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-02-05,
as a MIME invoice unpacking the file `fetchmail-6.3.7-rc1.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-02-03,
as a MIME invoice unpacking the file `fetchmail-6.3.7-rc1.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.7-rc1.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.7-rc1.pot
>    http://translation.sf.net/domains/POT/fetchmail-6.3.7-rc1.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.7-rc1.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...

[fetchmail-devel] fetchmail 6.3.7-rc1 release candidate

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

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

Greetings,

The security fixes in 6.3.6 also had side effects, and broke these two
features:
- - KPOP authentication
- - repolling without TLS if opportunistic upgrade to TLS failed for POP3

I have uploaded the fetchmail 6.3.7 release candidate to the usual download location:
<http://home.pages.de/~mandree/fetchmail/> - this should become the
final 6.3.7 release quite soon - unless further regressions or critical
bugs are reported.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
fetchmail 6.3.7 changes since 6.3.6:

# FIXES FOR REGRESSIONS IN 6.3.6
* Fix KPOP. Patch by Miloslav Trmac.
* Fix repoll when server disconnects after opportunistic TLS failed for POP3.
  Berlios Bug #10133, reported by Andrej Kacian.

# TRANSLATION UPDATES
* Japanese (Takeshi Hamasaki), Polish (Jakub Bogusz)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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)

iD8DBQFFw9f2vmGDOQUufZURAvhJAKCNcHhCUFf2aZ+yj3zDjomHgyGK1ACeO9DN
y4oyx3Dl4EHy/3vvSKE4prs=
=QH4/
-----END PGP SIGNATURE-----

Re: [fetchmail-devel] [PATCH] Fix KPOP

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

On Wed, 31 Jan 2007, Miloslav Trmac wrote:

> The only KPOP server I could find is cyrus-imapd, which completely
> ignores the password submitted with PASS.  I wasn't able to find any
> specification of KPOP, so I don't know for sure.  I can imagine a server
> that requires both Kerberos authentication and the correct password.

Does KPOP still work with the attached patch? (Apply on top of your
patch.)

-- 
Matthias Andree

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

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

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

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

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

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

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

Re: [fetchmail-devel] [PATCH] Fix KPOP

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

Matthias Andree napsal(a):
> Perhaps I'm paranoid, but I would like to make sure that this KPOP PASS
> %s can only ever send a fake password rather than the real one.
> I'm assuming here that the KPOP stuff relies on a Kerberos ticket the
> user has authenticated for separately, for instance, with kinit.
> 
> Questions:
> 1. Is my assumption above correct?
The only KPOP server I could find is cyrus-imapd, which completely
ignores the password submitted with PASS.  I wasn't able to find any
specification of KPOP, so I don't know for sure.  I can imagine a server
that requires both Kerberos authentication and the correct password.

> 2. Can we send "PASS password" or "PASS secret" or "PASS
>    using-kerberos-ticket-instead" literally, without falling back to the
>    ->password field, in case the user accidentally configures it or leaves
>    it in after switching to Kerberized POP?
See 1.

> 3. Could some arrange a login and mail address for me on a KPOP server
>    so I can test?  As far as I understand, KPOP implies POP3 on port 1109
>    with out-of-band Kerberos IV authentication. (or perhaps Krb. V).
I'm afraid I don't have a permanently running computer available on
which I could set this up.
	Mirek

[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.6.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.6.pot
>    http://translation.sf.net/domains/POT/fetchmail-6.3.6.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.6.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] [PATCH] Fix KPOP

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

Miloslav Trmac schrieb am 2007-01-23:

> fetchmail-6.3.6 restricts which authentication types may attempt to use
> the PASS command for authentication.  KPOP is using PASS as well,
> although it ignores the password, so KPOP is broken in 6.3.6.  The
> attached patch fixes the problem.

Thank you, Mirek.

Perhaps I'm paranoid, but I would like to make sure that this KPOP PASS
%s can only ever send a fake password rather than the real one.
I'm assuming here that the KPOP stuff relies on a Kerberos ticket the
user has authenticated for separately, for instance, with kinit.

Questions:
1. Is my assumption above correct?

2. Can we send "PASS password" or "PASS secret" or "PASS
   using-kerberos-ticket-instead" literally, without falling back to the
   ->password field, in case the user accidentally configures it or leaves
   it in after switching to Kerberized POP?

3. Could some arrange a login and mail address for me on a KPOP server
   so I can test?  As far as I understand, KPOP implies POP3 on port 1109
   with out-of-band Kerberos IV authentication. (or perhaps Krb. V).

There is another 6.3.6 regression in the BerliOS bug tracker, so I'm
leaning towards a 6.3.7 release with just fixes for the two 6.3.6
regressions I know.

If someone has observed another regression, speak up *now*.

Thanks,

> --- fetchmail-6.3.6/pop3.c.kpop	2007-01-22 23:42:14.000000000 +0100
> +++ fetchmail-6.3.6/pop3.c	2007-01-22 23:44:28.000000000 +0100
> @@ -612,7 +612,11 @@
>  
>  	/* check if we are actually allowed to send the password */
>  	if (ctl->server.authenticate == A_ANY
> -		|| ctl->server.authenticate == A_PASSWORD) {
> +	    || ctl->server.authenticate == A_PASSWORD
> +	    || ((ctl->server.authenticate == A_KERBEROS_V4
> +		 || ctl->server.authenticate == A_KERBEROS_V5)
> +		&& ctl->server.service
> +		&& strcmp(ctl->server.service, KPOP_PORT) == 0)) {
>  	    strlcpy(shroud, ctl->password, sizeof(shroud));
>  	    ok = gen_transact(sock, "PASS %s", ctl->password);

I'd use sock, "PASS something" (without %s and without ctl->password)
here for KPOP if possible. Does that work?

Thanks

-- 
Matthias Andree

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

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

Patch #1859 has been updated. 

Project: fetchmail
Category: None
Status: Open
Submitted by: bjk
Assigned to : none
Summary: PWMD support

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

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

[fetchmail-devel] [Bug #10133] fetchmail-6.3.6 SSL/TLS negotation fails on some servers

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

Bug #10133, was updated on 2007-Jan-27 11:40
Here is a current snapshot of the bug.

Project: Community Fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: ticho
Assigned to : none
Summary: fetchmail-6.3.6 SSL/TLS negotation fails on some servers

Details: Hello,
I'm pushing upstream a bug that was reported in Gentoo Bugzilla as bug #163782.

Here is output from fetchmail 6.3.4 and 6.3.6. Note that 6.3.4 works nicely with TLS1.

# fetchmail -v --check -N -f /etc/fetchmailrc 
fetchmail: WARNING: Running as root is discouraged.
fetchmail: 6.3.6 querying gye.satnet.net (protocol POP3) at Thu Jan 25 12:23:05
2007: poll started
Trying to connect to XXX.XXX.XXX.XXX/110...connected.
fetchmail: POP3< +OK Hello there.
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Here's what I can do:
fetchmail: POP3< STLS
fetchmail: POP3< TOP
fetchmail: POP3< USER
fetchmail: POP3< LOGIN-DELAY 10
fetchmail: POP3< PIPELINING
fetchmail: POP3< UIDL
fetchmail: POP3< IMPLEMENTATION Courier Mail Server
fetchmail: POP3< .
fetchmail: POP3> STLS
fetchmail: POP3< +OK Begin SSL/TLS negotiation now.
fetchmail: gye.satnet.net: opportunistic upgrade to TLS failed, trying to
continue.
fetchmail: POP3> USER <username>
fetchmail: Unknown login or authentication error on <username>@gye.satnet.net
fetchmail: socket error while fetching from <username>@gye.satnet.net

If I force no SSL, it works fine, though. Note that if I use version 6.3.4, I
have no problems using SSL mode:

# fetchmail -v --check -N -f /etc/fetchmailrc 
fetchmail: WARNING: Running as root is discouraged.
fetchmail: 6.3.4 querying gye.satnet.net (protocol POP3) at Thu Jan 25 12:32:05
2007: poll started
fetchmail: POP3< +OK Hello there.
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Here's what I can do:
fetchmail: POP3< STLS
fetchmail: POP3< TOP
fetchmail: POP3< USER
fetchmail: POP3< LOGIN-DELAY 10
fetchmail: POP3< PIPELINING
fetchmail: POP3< UIDL
fetchmail: POP3< IMPLEMENTATION Courier Mail Server
fetchmail: POP3< .
fetchmail: POP3> STLS
fetchmail: POP3< +OK Begin SSL/TLS negotiation now.
fetchmail: Repoll immediately on <username>@gye.satnet.net
fetchmail: POP3< +OK Hello there.
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Here's what I can do:
fetchmail: POP3< STLS
fetchmail: POP3< TOP
fetchmail: POP3< USER
fetchmail: POP3< LOGIN-DELAY 10
fetchmail: POP3< PIPELINING
fetchmail: POP3< UIDL
fetchmail: POP3< IMPLEMENTATION Courier Mail Server
fetchmail: POP3< .
fetchmail: POP3> USER <username>
fetchmail: POP3< +OK Password required.
fetchmail: POP3> PASS *
fetchmail: POP3< +OK logged in.
fetchmail: POP3> STAT
fetchmail: POP3< +OK 0 0
fetchmail: No mail for <username> at gye.satnet.net
fetchmail: POP3> QUIT

I was able to reproduce this myself with different error message from the server:

fetchmail: 6.3.6 querying gye.satnet.net (protocol POP3) at So 27. január 2007, 11:40:13 CET: poll started
Trying to connect to 200.63.192.22/110...connected.
fetchmail: POP3< +OK Hello there.
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Here's what I can do:
fetchmail: POP3< STLS
fetchmail: POP3< TOP
fetchmail: POP3< USER
fetchmail: POP3< LOGIN-DELAY 10
fetchmail: POP3< PIPELINING
fetchmail: POP3< UIDL
fetchmail: POP3< IMPLEMENTATION Courier Mail Server
fetchmail: POP3< .
fetchmail: POP3> STLS
fetchmail: POP3< +OK Begin SSL/TLS negotiation now.
fetchmail: gye.satnet.net: upgrade to TLS failed.
fetchmail: Unknown login or authentication error on ti...@gy...
fetchmail: socket error while fetching from ti...@gy...
fetchmail: 6.3.6 querying gye.satnet.net (protocol POP3) at So 27. január 2007, 11:40:14 CET: poll completed
fetchmail: Query status=2 (SOCKET)
fetchmail: normal termination, status 2

The .fetchmailrc I used for this test was:

poll gye.satnet.net
	proto pop3
	user ticho
	pass "asd"
	is ticho
	sslproto TLS1
	fetchall
	keep

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

[fetchmail-devel] [PATCH] Fix KPOP

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

Hello,
fetchmail-6.3.6 restricts which authentication types may attempt to use
the PASS command for authentication.  KPOP is using PASS as well,
although it ignores the password, so KPOP is broken in 6.3.6.  The
attached patch fixes the problem.

Thanks,
	Mirek

[fetchmail-devel] Lotus Notes support

[Jan-Benedict G. <jb...@te...>]

Hi!

Due to some reasons, the company I work for is mostly
switching to use Lotus Notes for the near future.
However, there are a lot of scripts around that are fed
with plain emails (eg. from within mutt) to automate
a lot of stuff.

We're thinking about implementing a program using the
Lotus Notes C API to suck mails out of the Domino server.
If you'd accept patches extending fetchmail to do that
(which would probably require some additional config
options), I'd start with the fetchmail codebase.
However, the C API is no Free Software, it's basically
a proprietary IBM library.

Thanks, JBG
-- 
Telefónica Deutschland GmbH     | Jan-Benedict Glaw
Hülshorstweg 30                 | Configuration Management
33415 Verl                      | Email: <jb...@te...>
http://www.telefonica.de/       | Tel.: +49-5246-80-1869

[fetchmail-devel] fetchmail security announcement 2006-03 (CVE-2006-5974)

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

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

fetchmail-SA-2006-03: crash when refusing message delivered through MDA

Topics:		fetchmail crashes when refusing a message bound for an MDA

Author:		Matthias Andree
Version:	1.0
Announced:	2007-01-04
Type:		denial of service
Impact:		fetchmail aborts prematurely
Danger:		low
Credits:	Neil Hoggarth (bug report and analysis)
CVE Name:	CVE-2006-5974
URL:		http://fetchmail.berlios.de/fetchmail-SA-2006-03.txt
Project URL:	http://fetchmail.berlios.de/

Affects:	fetchmail release = 6.3.5
		fetchmail release candidates 6.3.6-rc1, -rc2

Not affected:	fetchmail release 6.3.6

Corrected:	2006-11-14 fetchmail SVN


0. Release history
==================

2006-11-19 -	internal review draft
2007-01-04 1.0	 ready for release


1. Background
=============

fetchmail is a software package to retrieve mail from remote POP2, POP3,
IMAP, ETRN or ODMR servers and forward it to local SMTP, LMTP servers or
message delivery agents.

fetchmail ships with a graphical, Python/Tkinter based configuration
utility named "fetchmailconf" to help the user create configuration (run
control) files for fetchmail.


2. Problem description and Impact
=================================

Fetchmail 6.3.5 and early 6.3.6 release candidates, when delivering
messages to a message delivery agent by means of the "mda" option, can
crash (by passing a NULL pointer to ferror() and fflush()) when refusing
a message. SMTP and LMTP delivery modes aren't affected.


3. Workaround
=============

Avoid the mda option and ship to a local SMTP or LMTP server instead.


4. Solution
===========

Download and install fetchmail 6.3.6 or a newer stable release from
fetchmail's project site at
<http://developer.berlios.de/project/showfiles.php?group_id=1824>.



A. Copyright, License and Warranty
==================================

(C) Copyright 2007 by Matthias Andree, <mat...@gm...>.
Some rights reserved.

This work is licensed under the Creative Commons
Attribution-NonCommercial-NoDerivs German License. To view a copy of
this license, visit http://creativecommons.org/licenses/by-nc-nd/2.0/de/
or send a letter to Creative Commons; 559 Nathan Abbott Way;
Stanford, California 94305; USA.

THIS WORK IS PROVIDED FREE OF CHARGE AND WITHOUT ANY WARRANTIES.
Use the information herein at your own risk.

END OF fetchmail-SA-2006-03.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFntkCvmGDOQUufZURApmyAKCV50Rs96vyEl8L8oXsMiIam064IwCg08KI
HWQ3SfEpc6WV4bS+xZwWj5g=
=JZIR
-----END PGP SIGNATURE-----

[fetchmail-devel] fetchmail security announcement 2006-02 (CVE-2006-5867)

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

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

fetchmail-SA-2006-02: TLS enforcement problem/MITM attack/password exposure

Topics:		fetchmail cannot enforce TLS

Author:		Matthias Andree
Version:	1.0
Announced:	2007-01-04
Type:		secret information disclosure
Impact:		fetchmail can expose cleartext password over unsecure link
		fetchmail may not detect man in the middle attacks
Danger:		medium
Credits:	Isaac Wilcox (bug report, testing, collaboration on fix)
CVE Name:	CVE-2006-5867
URL:		http://fetchmail.berlios.de/fetchmail-SA-2006-02.txt
Project URL:	http://fetchmail.berlios.de/

Affects:	fetchmail releases <= 6.3.5
		fetchmail release candidates 6.3.6-rc1, -rc2, -rc3

Not affected:	fetchmail release candidates 6.3.6-rc4, -rc5
		fetchmail release 6.3.6

Corrected:	2006-11-26 fetchmail 6.3.6-rc4


0. Release history
==================

2006-11-16	v0.01 internal review draft
2006-11-26	v0.02 revise failure cases, workaround, add acknowledgments
2006-11-27	v0.03 add more vulnerabilities
2006-01-04	v1.0  ready for release


1. Background
=============

fetchmail is a software package to retrieve mail from remote POP2, POP3,
IMAP, ETRN or ODMR servers and forward it to local SMTP, LMTP servers or
message delivery agents.

fetchmail ships with a graphical, Python/Tkinter based configuration
utility named "fetchmailconf" to help the user create configuration (run
control) files for fetchmail.


2. Problem description and Impact
=================================

Fetchmail has had several nasty password disclosure vulnerabilities for
a long time. It was only recently that these have been found.

V1. sslcertck/sslfingerprint options should have implied "sslproto tls1"
    in order to enforce TLS negotiation, but did not.

V2. Even with "sslproto tls1" in the config, fetches would go ahead
    in plain text if STLS/STARTTLS wasn't available (not advertised,
    or advertised but rejected).

V3. POP3 fetches could completely ignore all TLS options whether
    available or not because it didn't reliably issue CAPA before
    checking for STLS support - but CAPA is a requisite for STLS.
    Whether or not CAPAbilities were probed, depended on the "auth"
    option. (Fetchmail only tried CAPA if the auth option was not set at
    all, was set to gssapi, kerberos, kerberos_v4, otp, or cram-md5.)

V4. POP3 could fall back to using plain text passwords, even if strong
    authentication had been configured.

V5. POP2 would not complain if strong authentication or TLS had been
    requested.

This can cause eavesdroppers to obtain the password, depending on the
authentication scheme that is configured or auto-selected, and
subsequently impersonate somebody else when logging into the upstream
server.


3. Workaround
=============

If your upstream offers SSLv3-wrapped service on a dedicated port,
use   fetchmail --ssl --sslcertck --sslproto ssl3   on the command line,
or equivalent in the run control file.  This encrypts the whole session.


4. Solution
===========

Download and install fetchmail 6.3.6 or a newer stable release from
fetchmail's project site at
<http://developer.berlios.de/project/showfiles.php?group_id=1824>.


5. Acknowledgments
==================

Isaac Wilcox has been a great help with testing the fixes and getting
them right.


A. Copyright, License and Warranty
==================================

(C) Copyright 2007 by Matthias Andree, <mat...@gm...>.
Some rights reserved.

This work is licensed under the Creative Commons
Attribution-NonCommercial-NoDerivs German License. To view a copy of
this license, visit http://creativecommons.org/licenses/by-nc-nd/2.0/de/
or send a letter to Creative Commons; 559 Nathan Abbott Way;
Stanford, California 94305; USA.

THIS WORK IS PROVIDED FREE OF CHARGE AND WITHOUT ANY WARRANTIES.
Use the information herein at your own risk.

END OF fetchmail-SA-2006-02.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFntjCvmGDOQUufZURAtNMAJ9OstcwdVdVUn4/suqZ5JZeTqot+QCgiCdv
gxYMyVLO7WBDL4+jiB6WxR8=
=VryG
-----END PGP SIGNATURE-----

[fetchmail-devel] fetchmail 6.3.6 security fix release

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

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

Greetings and a happy new year,

I am announcing the release of fetchmail 6.3.6. This new stable version
of fetchmail fixes a major and a minor security issue (CVE-2006-5867 and
CVE-2006-5974), fixes some regressions that appeared in 6.3.5 and other
minor bugs.

- -----------------------------------------------------------------------
NOTE THAT THE CCIL.ORG MAILING LISTS ARE DEPRECATED AND NO LONGER
ACCEPT POSTINGS OR SUBSCRIPTIONS. Please subscribe to the new lists at
<https://developer.berlios.de/mail/?group_id=1824>:
- - for fetchmail-announce subscribers: subscribe to fetchmail-announce
- - for fetchmail-friends subscribers: subscribe to fetchmail-users
- -----------------------------------------------------------------------

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

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

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

fetchmail 6.3.6 (released 2007-01-04):

# SECURITY FIXES:
* CVE-2006-5867, fetchmail-SA-2006-02.txt:
  Password disclosure vulnerability fixed. This has several aspects:

  - Fetchmail now implies sslproto 'tls1' if the sslfingerprint or sslcertck
    options are used and the ssl option is not used, in order to be sure that
    fetchmail gets a certificate from the mail server.

  - Fetchmail breaks the connection if the TLS negotiation (or verification, if
    requested) fails with sslproto 'tls1', sslfingerprint or sslcheck enabled.

  - POP3 connections now use STLS reliably. They used to ignore STLS altogether
    for serveral values of the "auth" option, when fetchmail forget to probe
    server capabilities - see fetchmail-SA-2006-02.txt for details.

  - POP3 connections will no longer fall back USER/PASS authentication if
    strong challenge-response authenticators such as CRAM-MD5 are configured
    but the server does not advertise these in its CAPA response.

  - POP2 is obsolete and does not support STLS or anything beyond password-based
    authentication. The attempt to use STLS or strong authenticators now causes
    connection abort.

  Configurations using both ssl and sslcertck however have been semi-safe in
  that they would send the password in the clear. The USER/PASS fallback
  problem however applies to these too, so that the password was only change on
  trustworthy servers.

* CVE-2006-5974, fetchmail-SA-2006-03.txt:
  Repairs a regression in 6.3.5 that crashes fetchmail when a message with
  invalid headers is found while fetchmail's mda option is in use. BerliOS bugs
  #9364, #9412, #9449. Stack backtrace provided by Neil Hoggarth - thanks.

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

# REGRESSION FIXES (recently introduced bugs):
* Repair --logfile, broken in 6.3.5. BerliOS Bug #9059,
  reported by Brian Harring.
* Repair --user, broken in 6.3.5 (as a side effect of the authenticate external
  patch): using SSL certificate/key authentication overrode the --user option.
  Now the latter takes precedence, and only defaults to the certificate's common
  name.  Debian Bug #400950, reported by Jorgen Schaefer <fo...@de...>.

# BUG FIXES (long-standing bugs):
* RPOP: used to log the password locally rather than an asterisk as the other
  protocols do. The password is now shrouded in the local logs.
* POP3: Probes capabilities now when Kerberos V5 is enabled, so that we can
  actually detect if the server supports it.
* Robustness: If a stale lockfile cannot be deleted, truncate it so that
  fetchmail doesn't later believe itself to be running if the PID is recycled
  by a non-fetchmail process.
* DNS: Detect /etc/resolv.conf changes: On systems that have res_search(),
  assume we also have res_init() and call it (suggested by Ulrich Drepper,
  glibc bug #3675) in order to make libc or libresolv reread the resolver
  configuration at the beginning of a poll cycle.  This is important when
  fetchmail is in daemon mode and /etc/resolv.conf is changed later by dhcpcd,
  dhclient, pppd, openvpn or other ip-up/ipchange scripts.  Should fix Debian
  Bug#389270, Bug#391698.
* Robustness: Fix crash on systems that do not provide strdup(), the crash
  happens only in out-of-memory conditions when fetchmail cannot proceed
  anyways.  Patch by Andreas Krennmair.
* Robustness: When HOME and FETCHMAILHOME are unset, be sure to copy user
  database information, so it is not trashed later. Patch by Jim Correia.

# CHANGES:
* Workaround: Improve handling of IMAP IDLE, some servers do not reset their
  time counters after sending information asynchronously. Patch by Sunil
  Shetye, after report from Andrew Baumann.
* Usability: When requesting Kerberos or GSSAPI, complain and exit with syntax
  error if any of these requested features has not been compiled in.  This is
  to fail early and with precise error message. Reported by Isaac Wilcox.
* --version will now add +KRB4 or +KRB5 if Kerberos v4 or v5, respectively, have
  been compiled in. Reported missing by Isaac Wilcox.

# TRANSLATIONS:
* New en_GB (British English) translation by David Lodge.
* Update Japanese (Takeshi Hamasaki), Polish (Jakub Bogusz), Russian (Pavel
  Maryanov) and Vietnamese (Clytie Siddall) translations.
! Note that not all these translations are complete -- this isn't the
  translators' fault though, but due to delays at the BerliOS hosting site and
  the translation project handlers. You may see a few untranslated messages.

# DOCUMENTATION:
* Dropped exit status 15 from manual page, it's not used by fetchmail.
  Reported by Isaac Wilcox.
* Documented exit codes 24 - 29 as internal.

# 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)
* 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 expects Received: headers in a particular, but undocumented, format
  when parsing envelopes.
* 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

Regards,

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

iD8DBQFFnthUvmGDOQUufZURAqyCAJ9M9o7uj3rH4cnU7teWvqQdb6vjQgCg7v0L
OaufKzrR7WwaKC28lUepevw=
=3FrE
-----END PGP SIGNATURE-----

Re: [fetchmail-devel] [PATCH] interface.c remove useless code

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

Nico Golde schrieb am 2006-12-30:

> small patch to remove useless patch in interface.c

No, that code actually has a purpose - sp points inside ifname, purpose
is to hide the slash and remainder of string in ifname from the function
call following the allegedly useless code.

Sorry!

-- 
Matthias Andree

[fetchmail-devel] [PATCH] interface.c remove useless code

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

Hi,
small patch to remove useless patch in interface.c
Kind regards
Nico

-- 
Nico Golde - http://www.ngolde.de
JAB: ni...@ja... - GPG: 0x73647CFF
Forget about that mouse with 3/4/5 buttons,
gimme a keyboard with 103/104/105 keys!

[fetchmail-devel] fetchmail 6.3.6-rc5 final release candidate

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

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

Greetings,

After several more bugs had to be fixed, I have uploaded the fifth
fetchmail 6.3.6 release candidate to the usual download location:
<http://home.pages.de/~mandree/fetchmail/> - this should become the
final 6.3.6 release soon.

It fixes the --sslcert vs. --user regression seen in 6.3.5,
it fixes the long-standing "doesn't detect /etc/resolv.conf changes"
issue that broke DNS resolving on so many systems, makes IMAP IDLE
handling more robust vs. server timeouts and adds a few other minor
changes - see the next section for details.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
fetchmail 6.3.6-rc5 changes (versus -rc4) are:

# REGRESSION FIX:
* In 6.3.5 (as a side effect of the authenticate external patch), using SSL
  certificate/key authentication overrode the --user option. Now the latter
  takes precedence, and only defaults to the certificate's common name.
  Debian Bug #400950, reported by Jorgen Schaefer <fo...@de...>.

# BUG FIXES:
* On systems that have res_search(), assume we also have res_init() and call it
  (suggested by Ulrich Drepper, glibc bug #3675) in order to make libc or
  libresolv reread the resolver configuration at the beginning of a poll cycle.
  This is important when fetchmail is in daemon mode and /etc/resolv.conf is
  changed later by dhcpcd, dhclient, pppd, openvpn or other ip-up/ipchange
  scripts.  Should fix Debian Bug#389270, Bug#391698.
* Fix crash on systems that do not provide strdup(), the crash then happens in
  out-of-memory conditions.  Patch by Andreas Krennmair.

# CHANGES:
* Remove excess no-op strcpy() after strdup() found by Andreas Krennmair.
* Remove handling for PS_TRUNCATED (code 27), which was never asserted.
* Improve handling of IMAP IDLE, some servers do not reset their time counters
  after sending information asynchronously. Patch by Sunil Shetye, after report
  from Andrew Baumann.
* When requesting Kerberos V4, V5 or GSSAPI, complain and exit with syntax error
  if any of these requested features has not been compiled in. Reported by Isaac
  Wilcox.
* --version will now add +KRB4 or +KRB5 if Kerberos v4 or v5, respectively, have
  been compiled in. Reported by Isaac Wilcox.

# DOCUMENTATION:
* Dropped exit status 15 from manual page, it's not used by fetchmail.
  Reported by Isaac Wilcox.
* Documented exit codes 24 - 29 as internal.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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)

iD8DBQFFhzVfvmGDOQUufZURAqM3AJ94TzwwVttbLXy1IFM4/dXvoj4jtgCgxZdm
ATncf/Di6YiqLUddIrBpZ3Q=
=2tcR
-----END PGP SIGNATURE-----