fetchmail-devel — Development related discussion

[fetchmail-devel] New Italian PO file for 'fetchmail' (version 6.3.15-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Italian team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/it.po

(This file, 'fetchmail-6.3.15-pre1.it.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

Re: [fetchmail-devel] fetchmail 6.3.15-beta1 beta release with "bad-header pass" feature

[Frédéric M. <fre...@wo...>]

On Wednesday 24 February 2010, Matthias Andree wrote:
> Greetings,
>
> I am asking interested fetchmail users to test a BETA release of
> fetchmail.  This beta1 has the long-desired feature to ignore bad
> headers in messages and pass them on.  Note that this features is OFF BY
> DEFAULT and YOU need to turn it on explicitly by command line or rcfile.
>
> The beta software is available from:
> <http://home.pages.de/~mandree/fetchmail/>

Two really minor observations so far.

The localdomains option cannot be shortened as local as specified in the man 
page (that may not be new, I'm coming from 6.3.9).

If bad-headers pass is set after a user option, fetchmail complains 
with "server option after user options at pass". That's a little bit 
confusing if password is shortened as pass too.

Frederic

[fetchmail-devel] Corrections for fr.po in fetchmail-6.3.15-beta1

[Frédéric M. <fre...@wo...>]

Hello,

May I meddle into this and propose a corrected translation file for the French 
language ?

I have translated the missing sentences, corrected the spelling as much as I 
could and revised the fuzzy entries.

Frederic

[fetchmail-devel] New Czech PO file for 'fetchmail' (version 6.3.15-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Czech team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/cs.po

(This file, 'fetchmail-6.3.15-pre1.cs.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New template for 'fetchmail' made available

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to <coo...@tr...>.)

A new POT file for textual domain 'fetchmail' has been made available
to the language teams for translation.  It is archived as:

    http://translationproject.org/POT-files/fetchmail-6.3.15-pre1.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

    http://www.dt.e-technik.uni-dortmund.de/~ma/fetchmail/fetchmail-6.3.15-beta1.tar.bz2

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

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] fetchmail 6.3.15-beta1 beta release with "bad-header pass" feature

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

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

Greetings,

I am asking interested fetchmail users to test a BETA release of
fetchmail.  This beta1 has the long-desired feature to ignore bad
headers in messages and pass them on.  Note that this features is OFF BY
DEFAULT and YOU need to turn it on explicitly by command line or rcfile.

The beta software is available from:
<http://home.pages.de/~mandree/fetchmail/>

These are the relevant changes since the previous release.  Unless
otherwise noted, changes to this release were made by Matthias Andree:

# FEATURE
* Fetchmail now supports a bad-header command line or rcfile option that takes
  exactly one argument, pass or reject (default).  If set to pass, fetchmail
  will pass messages with bad headers on.  This has been rejected for a long
  time, and the right behaviour was disputed for too long.

# CHANGES
* The repository has been converted and moved from the Subversion (SVN) format
  kindly hosted by Graham Wilson over the past years to Git format hosted on
  Gitorious.org.  My deepest thanks to Graham Wilson for this service that
  kept us going when BerliOS's Subversion service was faulty in its early days.
* This opportunity was used to convert BRANCH_6-2 and BRANCH_1-9-9 to
  GnuPG-signed tags, as a sign that these are now closed.
* The outdated SVN trunk is now called "oldtrunk" in Git just to save the work
  for future reference. All development in the past few years was on BRANCH_6-3.
* master was branched from BRANCH_6-3 for user convenience.

# DOCUMENTATION
* Web site and documentation were adjusted to reflect the SVN->Git move.
* The fetchmail manual page is now much clearer on the user id switching
  (seteuid) when using --mda while running as the super user.

- -- 
Matthias Andree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEARECAAYFAkuEgMoACgkQvmGDOQUufZV3mQCgtp8ccaUDTU7zhmL4CNilZzQZ
uqAAnRraStvFdKswS8s1KFMyEi2w4wNy
=neOa
-----END PGP SIGNATURE-----

[fetchmail-devel] function to read configuration file

[Fabio M. <fab...@du...>]

Hi all,
I'm trying to change fetchmail code to add crypted password in fetchmailrc.

I would decrypt password in function that reads fetchmailrc 
configuration file, but I can not find this function.

Anyone can help me?

Thanks in advance,
Fabio

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

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

Patch #1859 has been updated. 

Project: fetchmail
Category: None
Status: Open
Submitted by: bjk
Assigned to : m-a
Summary: PWMD support

Follow-Ups:

Date: 2010-Feb-11 02:44
By: m-a

Comment:
Hi Ben,

thanks for keeping this feature up to date.

I've recently migrated the source code management to Git and it's hosted on http://gitorious.org/fetchmail/ (free of charge) - that site allows easy cloning and merging for such contributions, so it may be worth a spin.

I'd also be interested to merge, but we're a while back from that state where I'll have revived the 7.0 development branch sufficiently that it's worth doing.

Matthias

-------------------------------------------------------

Date: 2010-Feb-11 01:18
By: bjk

Comment:
Minor fix to patch against fetchmail 6.3.14.
-------------------------------------------------------

Date: 2010-Jan-13 23:11
By: bjk

Comment:
This new version fixes reconnecting to the same socket specified in the rcfile. Useful if there is more than one account specified which uses the same pwmd socket.
-------------------------------------------------------

Date: 2009-Apr-30 02:10
By: bjk

Comment:
Updated to use libpwmd6.
-------------------------------------------------------

Date: 2008-Oct-19 19:10
By: bjk

Comment:
Really use the pwmd pinentry method.
-------------------------------------------------------

Date: 2008-Jul-11 19:23
By: bjk

Comment:
Now uses pwmds (v1.11) pinentry method for pinentry timeouts.
-------------------------------------------------------

Date: 2008-Jan-26 20:09
By: bjk

Comment:
Another fix for lock file checking.
-------------------------------------------------------

Date: 2008-Jan-12 21:37
By: bjk

Comment:
This re-adds pinentry timeout support and fixes the previous patch complaining about an existing fetchmail running.
-------------------------------------------------------

Date: 2008-Jan-06 19:05
By: bjk

Comment:
Updated to work with libpwmd5. This revision removes pinentry timeouts so make sure the password is cached on the server when running in daemon mode otherwise if your away pinentry will block the fetchmail daemon waiting for input. It also checks the pwmd server at each poll interval.
-------------------------------------------------------

Date: 2007-Oct-20 19:53
By: bjk

Comment:
Here's a new patch for fetchmail 6.3.8 and libpwmd4. Includes pinentry settings. I'm not sure how to handle timeouts and errors connecting to pwmd. As it is now it'll exit like fetchmail does when it encounters an rcfile parse error.
-------------------------------------------------------

Date: 2007-Feb-17 17:47
By: bjk

Comment:
Password Manager Daemon. It servers clients data whch is stored in an encrypted XML file. A client connects, provides a password to open a file and issues protocol commands to manipulate the data. It's a work in progress.

The fetchmail patch uses PWMD to get server info (hostname, sslfingerprint, port, etc), username and password info.
-------------------------------------------------------

Date: 2007-Feb-16 23:42
By: m-a

Comment:
What's PWMD?
-------------------------------------------------------

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

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

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

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

Patch #1859 has been updated. 

Project: fetchmail
Category: None
Status: Open
Submitted by: bjk
Assigned to : m-a
Summary: PWMD support

Follow-Ups:

Date: 2010-Feb-10 19:18
By: bjk

Comment:
Minor fix to patch against fetchmail 6.3.14.
-------------------------------------------------------

Date: 2010-Jan-13 17:11
By: bjk

Comment:
This new version fixes reconnecting to the same socket specified in the rcfile. Useful if there is more than one account specified which uses the same pwmd socket.
-------------------------------------------------------

Date: 2009-Apr-29 20:10
By: bjk

Comment:
Updated to use libpwmd6.
-------------------------------------------------------

Date: 2008-Oct-19 13:10
By: bjk

Comment:
Really use the pwmd pinentry method.
-------------------------------------------------------

Date: 2008-Jul-11 13:23
By: bjk

Comment:
Now uses pwmds (v1.11) pinentry method for pinentry timeouts.
-------------------------------------------------------

Date: 2008-Jan-26 14:09
By: bjk

Comment:
Another fix for lock file checking.
-------------------------------------------------------

Date: 2008-Jan-12 15:37
By: bjk

Comment:
This re-adds pinentry timeout support and fixes the previous patch complaining about an existing fetchmail running.
-------------------------------------------------------

Date: 2008-Jan-06 13:05
By: bjk

Comment:
Updated to work with libpwmd5. This revision removes pinentry timeouts so make sure the password is cached on the server when running in daemon mode otherwise if your away pinentry will block the fetchmail daemon waiting for input. It also checks the pwmd server at each poll interval.
-------------------------------------------------------

Date: 2007-Oct-20 13:53
By: bjk

Comment:
Here's a new patch for fetchmail 6.3.8 and libpwmd4. Includes pinentry settings. I'm not sure how to handle timeouts and errors connecting to pwmd. As it is now it'll exit like fetchmail does when it encounters an rcfile parse error.
-------------------------------------------------------

Date: 2007-Feb-17 11:47
By: bjk

Comment:
Password Manager Daemon. It servers clients data whch is stored in an encrypted XML file. A client connects, provides a password to open a file and issues protocol commands to manipulate the data. It's a work in progress.

The fetchmail patch uses PWMD to get server info (hostname, sslfingerprint, port, etc), username and password info.
-------------------------------------------------------

Date: 2007-Feb-16 17:42
By: m-a

Comment:
What's PWMD?
-------------------------------------------------------

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

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

Re: [fetchmail-devel] HEADS UP: fetchmail repository converted and moved

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

Matthias Andree schrieb am 2010-02-08:

> I have converted the fetchmail source code repository to Git[1] and moved  
> it to a new host[2] in Norway.
> 
> [1] http://git-scm.com/
> 
> [2] http://gitorious.org/fetchmail/
> 
> The latter offers access for git clone (through Git and HTTP protocols)  
> and an online repository browser, and the site runs free software.

Note that I have force-rebased the BRANCH_MAPI branch so it now hinges
on RELEASE_6-3-8, rather than dangle in mid air as it used to. This was
done to provide proper ancestry for BRANCH_MAPI so as to ease later
merging, and to avoid the use of graftpoints that would have to be
created manually after checkout.

I know that this practice is being frowned upon, but I think it's
warranted in this case to fix this SVN conversion error as soon as
possible.

If you haven't changed anything on BRANCH_MAPI, just force the next git
fetch or git pull.

If you have changed things on BRANCH_MAPI, please stash your changes
first, before pulling/fetching with --force.

If you have changes committed locally, please contact me.

Best regards
Matthias

[fetchmail-devel] New Vietnamese PO file for 'fetchmail' (version 6.3.14)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Vietnamese team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/vi.po

(This file, 'fetchmail-6.3.14.vi.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New Polish PO file for 'fetchmail' (version 6.3.14)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Polish team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/pl.po

(This file, 'fetchmail-6.3.14.pl.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] HEADS UP: fetchmail repository converted and moved

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

Greetings,

I have converted the fetchmail source code repository to Git[1] and moved  
it to a new host[2] in Norway.

[1] http://git-scm.com/

[2] http://gitorious.org/fetchmail/

The latter offers access for git clone (through Git and HTTP protocols)  
and an online repository browser, and the site runs free software.

I took the opportunity to rename branches a bit so as to adhere to Git  
conventions, and to make the most current software (BRANCH_6-3) the  
default checkout. Here's the list of correspondences between former SVN  
and current Git branches:

old SVN	new Git
--------------------
BRANCH_6-3  master (default branch, get this)
BRANCH_MAPI BRANCH_MAPI (development branch for MAPI integration, by  
Yang-Yan Li and Mojmir Svoboda)
trunk	    oldtrunk [3] (obsolete)
vendor*     vendor* (this was used for SVN module imports)
BRANCH_6-2  none (abandoned, branch converted to a tag)

The RELEASE_* and SNAPSHOT_* tags have been converted unchanged.

[3] This used to be a "future" version in the days of the early fetchmail  
6.3.n releases, but I stopped merging BRANCH_6-3 back intro trunk a long  
time ago because it was such a hassle in Subversion, and it's now  
outdated.	

Now, this means that:

- if you have uncommitted changes in the Subversion tree, update as soon  
as possible from SVN, and please contact me so we can arrange for a merge,  
possibly on your personal topic branch.

- mknod.org/svn/... URLs (links) will get outdated rather soon now,  
because Graham is about to decommission the service.


My deepest thanks go out to Graham Wilson (in Bcc:) who has voluntarily  
hosted the former Subversion repository for so many years, even after he  
quit co-maintaining fetchmail. It's been a good time with reliable service  
and it helped fetchmail development a lot. Thanks a million.

Let me know if you have any further questions.

Best

-- 
Matthias Andree

[fetchmail-devel] New Japanese PO file for 'fetchmail' (version 6.3.14)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Japanese team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/ja.po

(This file, 'fetchmail-6.3.14.ja.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New Indonesian PO file for 'fetchmail' (version 6.3.14)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Indonesian team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/id.po

(This file, 'fetchmail-6.3.14.id.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New Czech PO file for 'fetchmail' (version 6.3.14)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Czech team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/cs.po

(This file, 'fetchmail-6.3.14.cs.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New Italian PO file for 'fetchmail' (version 6.3.14)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Italian team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/it.po

(This file, 'fetchmail-6.3.14.it.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New template for 'fetchmail' made available

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to <coo...@tr...>.)

A new POT file for textual domain 'fetchmail' has been made available
to the language teams for translation.  It is archived as:

    http://translationproject.org/POT-files/fetchmail-6.3.14.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

    http://www.dt.e-technik.uni-dortmund.de/~ma/fetchmail/fetchmail-6.3.14.tar.bz2

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

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] fetchmail 6.3.14 security fix release and fetchmail-SA-2010-01 security announcement

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

Greetings,

I am announcing the release of fetchmail 6.3.14.  This new stable
version of fetchmail fixes a bug introduced into 6.3.11 that could cause
heap corruption in verbose mode when displaying X.509 SSL/TLS
certificates that contained characters with high bit set on platforms
where the "char" type is signed. 6.3.14 also fixes a variety of IMAP
bugs. See below for details. Unfortunately the CVE id hasn't yet been
assigned; once it has been, I will update the online version of the
security announcement.

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 since the previous release.  Unless
otherwise noted, changes to this release were made by Matthias Andree
(in fact, most fixes were by Sunil Shetye this time):

# SECURITY FIXES
* SSL/TLS certificate information is now also reported properly on computers
  that consider the "char" type signed. Fixes malloc() buffer overrun.
  Workaround for older versions: do not use verbose mode.
  See fetchmail-SA-2010-01.txt for details, including a minimal patch.

# BUG FIXES
* The IMAP client no longer skips messages from several IMAP servers including
  Dovecot if fetchmail's "idle" is in use.  Causes were that fetchmail (a)
  ignored some untagged responses when it should not (b) relied on EXISTS
  messages in response to EXPUNGE, which aren't mandated by RFC-3501 (the IMAP
  standard) and aren't sent by Dovecot either.
    Fix by Sunil Shetye (the fix also consolidates IMAP response handling,
  improving overall robustness of the IMAP client), bug report and testing by
  Matt Doran, with further hints from Timo Sirainen.
* The SMTP client now recovers from errors (such as servers dropping the
  connection after errors) when sending an RSET command.
    Fix by Sunil Shetye. Report by James Moe.
* The IMAP client now uses "SEARCH UNSEEN" rather than "SEARCH UNSEEN NOT
  DELETED" again on IMAP2, to fix a regression in fetchmail 6.2.5 reported by
  Will Stringer in June 2004. (Sunil Shetye)
* The IMAP client now uses "SEARCH UNSEEN UNDELETED" on IMAP4 and IMAP4r1
  servers (Sunil Shetye).
* Workaround: The IMAP client now falls back to "FETCH n:m FLAGS" if the server
  does not support "SEARCH". (Sunil Shetye)
* The IMAP client now requests message numbers in batches of 1,000 to avoid
  problems if there are more than 1860 unseen messages. (Sunil Shetye)
    Note that this wasn't security relevant because fetchmail would only read up
  to the maximum buffer size and leave the remainder of the string unread, going
  out of synch afterwards.
* Stricter validation of IMAP responses containing byte or message counts.

# CHANGES
* Only include gssapi.h if we're not including gssapi/gssapi.h, to fix a FreeBSD
  compiler warning about gssapi.h being obsolete.

# DOCUMENTATION
* The README.SSL document was revised for grammar, spelling, and clarity.
  Courtesy of Robert Mullin.

# TRANSLATION UPDATES
* [it]    Italian, by Vincenzo Campanella

-- 
Matthias Andree

Re: [fetchmail-devel] imap search improvements

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

Quoting from Matthias Andree's mail on Thu, Feb 04, 2010:
> > Please check the attached patch for improving imap search.
> 
> Good, applied as rev 5468.
> 
> Note I've added a patch on top of it - please check if that's OK to you.

Yeah, that looks okay.

> Note also that I'll likely be releasing 6.3.14 tonight to fix a security
> issue in verbose SSL/TLS certificate display on platforms where char is
> signed.  The paranoid and impatient may want to recompile fetchmail with
> "CC=gcc -funsigned-char" for the nonce.

Great.

-- 
Sunil Shetye.

[fetchmail-devel] [PATCH] minor compilation warnings patch

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

Hi Matthias,

This is a patch to fix a call to gen_transact() in cram.c. Please
check if my patch (i.e. my understanding of the code) is correct.

The rest of the patch is to suppress compiler warnings in tls.c and to
enable compiler warnings on incorrect invocation of SockPrintf().

============================================================================
Index: fetchmail-6.3/cram.c
===================================================================
--- fetchmail-6.3/cram.c	(revision 5469)
+++ fetchmail-6.3/cram.c	(working copy)
@@ -127,7 +127,7 @@
     /* ship the authentication back, accept the server's responses */
     /* PMDF5.2 IMAP has a bug that requires this to be a single write */
     suppress_tags = TRUE;
-    result = gen_transact(sock, buf1, sizeof(buf1));
+    result = gen_transact(sock, "%s", buf1);
     suppress_tags = FALSE;
     if (result)
 	return(result);
Index: fetchmail-6.3/tls.c
===================================================================
--- fetchmail-6.3/tls.c	(revision 5469)
+++ fetchmail-6.3/tls.c	(working copy)
@@ -16,6 +16,7 @@
     return (!ctl->sslproto || !strcasecmp(ctl->sslproto,"tls1"))
 	&& !ctl->use_ssl;
 #else
+    (void)ctl;
     return 0;
 #endif
 }
@@ -28,6 +29,7 @@
 	&& (ctl->sslfingerprint || ctl->sslcertck
 		|| (ctl->sslproto && !strcasecmp(ctl->sslproto, "tls1")));
 #else
+    (void)ctl;
     return 0;
 #endif
 }
Index: fetchmail-6.3/socket.h
===================================================================
--- fetchmail-6.3/socket.h	(revision 5469)
+++ fetchmail-6.3/socket.h	(working copy)
@@ -51,7 +51,9 @@
 Returns number of bytes successfully written.
 */
 #if defined(HAVE_STDARG_H)
-int SockPrintf(int sock, const char *format, ...) ;
+int SockPrintf(int sock, const char *format, ...)
+    __attribute__ ((format (printf, 2, 3)))
+    ;
 #else
 int SockPrintf();
 #endif
============================================================================

-- 
Sunil Shetye.

Re: [fetchmail-devel] [PATCH] Re: imap search improvements

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

Sunil Shetye schrieb am 2010-02-03:

> Hi Matthias,
> 
> Please check the attached patch for improving imap search.

Good, applied as rev 5468.

Note I've added a patch on top of it - please check if that's OK to you.

Note also that I'll likely be releasing 6.3.14 tonight to fix a security
issue in verbose SSL/TLS certificate display on platforms where char is
signed.  The paranoid and impatient may want to recompile fetchmail with
"CC=gcc -funsigned-char" for the nonce.


commit 63587e34de582abe3b4a611437fc2fce8b5bd81e
Author: m-a <m-a@6bd12b38-53dc-0310-98db-d94f1ca4f90c>
Date:   Thu Feb 4 09:51:08 2010 +0000

    Stricter validation of IMAP responses containing byte or message counts.
    
    git-svn-id: svn+ssh://mknod.org/svn/fetchmail/branches/BRANCH_6-3@5469 6bd12b38-53dc-0310-98db-d94f1ca4f90c

diff --git a/NEWS b/NEWS
index 4b64b64..565d7bd 100644
--- a/NEWS
+++ b/NEWS
@@ -79,6 +79,7 @@ fetchmail 6.3.14 (not yet released):
     Note that this wasn't security relevant because fetchmail would only read up
   to the maximum buffer size and leave the remainder of the string unread, going
   out of synch afterwards.
+* Stricter validation of IMAP responses containing byte or message counts.
 
 # CHANGES
 * Only include gssapi.h if we're not including gssapi/gssapi.h, to fix a FreeBSD
diff --git a/imap.c b/imap.c
index 89d486c..15a563e 100644
--- a/imap.c
+++ b/imap.c
@@ -74,7 +74,9 @@ static int imap_untagged_response(int sock, const char *buf)
     }
     else if (strstr(buf, " EXISTS"))
     {
-	count = atoi(buf+2);
+	char *t; unsigned long u;
+	errno = 0;
+	u = strtoul(buf+2, &t, 10);
 	/*
 	 * Don't trust the message count passed by the server.
 	 * Without this check, it might be possible to do a
@@ -82,11 +84,15 @@ static int imap_untagged_response(int sock, const char *buf)
 	 * count, and allocate a malloc area that would overlap
 	 * a portion of the stack.
 	 */
-	if ((unsigned)count > INT_MAX/sizeof(int))
+	if (errno /* strtoul failed */
+		|| t == buf+2 /* no valid data */
+		|| u > (unsigned long)(INT_MAX/sizeof(int)) /* too large */)
 	{
-	    report(stderr, GT_("bogus message count!"));
+	    report(stderr, GT_("bogus message count in \"%s\"!"), buf);
 	    return(PS_PROTOCOL);
 	}
+	count = u; /* safe as long as count <= INT_MAX - checked above */
+
 	if ((recentcount = count - oldcount) < 0)
 	    recentcount = 0;
 
@@ -117,14 +123,22 @@ static int imap_untagged_response(int sock, const char *buf)
 # if 0
     else if (strstr(buf, " RECENT"))
     {
+	/* fixme: use strto[u]l and error checking */
 	recentcount = atoi(buf+2);
     }
 # endif
     else if (strstr(buf, " EXPUNGE"))
     {
+	unsigned long u; char *t;
 	/* the response "* 10 EXPUNGE" means that the currently
 	 * tenth (i.e. only one) message has been deleted */
-	if (atoi(buf+2) > 0)
+	errno = 0;
+	u = strtoul(buf+2, &t, 10);
+	if (errno /* conversion error */ || t == buf+2 /* no number found */) {
+	    report(stderr, GT_("bogus EXPUNGE count in \"%s\"!"), buf);
+	    return PS_PROTOCOL;
+	}
+	if (u > 0)
 	{
 	    if (count > 0)
 		count--;
@@ -854,7 +868,8 @@ restartsearch:
 
 			errno = 0;
 			um = strtoul(cp,&ep,10);
-			if (errno == 0 && um <= UINT_MAX && um <= (unsigned)count)
+			if (errno == 0 && ep > cp
+				&& um <= INT_MAX && um <= (unsigned)count)
 			{
 			    unseen_messages[unseen++] = um;
 			    if (outlevel >= O_DEBUG)
@@ -912,7 +927,7 @@ fetchflags:
 	 */
 	if (unseen < count
 		&& sscanf(buf, "* %u FETCH ", &num) == 1
-		&& num >= 1 && num <= count
+		&& num >= 1 && num <= (unsigned)count
 		&& strstr(buf, "FLAGS ")
 		&& !strstr(buf, "\\SEEN")
 		&& !strstr(buf, "\\DELETED"))
@@ -1302,15 +1317,21 @@ static int imap_fetch_body(int sock, struct query *ctl, int number, int *lenp)
      * server called dbmail that returns huge garbage lengths.
      */
     if ((cp = strchr(buf, '{'))) {
+	long l; char *t;
         errno = 0;
-	*lenp = (int)strtol(cp + 1, (char **)NULL, 10);
-        if (errno == ERANGE || *lenp < 0)
-            *lenp = -1;    /* length is too big/small for us to handle */
-    }
-    else
+	++ cp;
+	l = strtol(cp, &t, 10);
+        if (errno || t == cp || (t && !strchr(t, '}')) /* parse error */
+		    || l < 0 || l > INT_MAX /* range check */) {
+	    *lenp = -1;
+	} else {
+	    *lenp = l;
+	}
+    } else {
 	*lenp = -1;	/* missing length part in FETCH reponse */
+    }
 
-    return(PS_SUCCESS);
+    return PS_SUCCESS;
 }
 
 static int imap_trail(int sock, struct query *ctl, const char *tag)

[fetchmail-devel] [PATCH] Re: imap search improvements

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

Hi Matthias,

Please check the attached patch for improving imap search.

Quoting from Matthias Andree's mail on Mon, Feb 01, 2010:
> > 1. In r3838, the "SEARCH UNSEEN" was changed to "SEARCH UNSEEN NOT
> > DELETED". Some imap servers do not support such a complex search
> > phrase. I could find only one reference for that:
> > 
> > http://lists.ccil.org/pipermail/fetchmail-friends/2004-June/008897.html
> > 
> > I propose that that change should be undone.

...

> The issue reported 5 years ago refers to a regression on IMAP2 servers, and a
> regression fix is also always acceptable (though 6.2.X remains unsupported by
> me, I'm not releasing another 6.2.X - the fix will go into 6.3.X then).
> 
> In the implementation of the fix, could you switch by protocol version to use
> the "... NOT DELETED" form for newer servers (IMAP4r1, not sure if IMAP4 also
> supports it), and the older "SEARCH UNSEEN" only in IMAP2?  That would give us
> the best of both approaches -- or perhaps we could just fall back to SEARCH
> UNSEEN if SEARCH UNSEEN NOT DELETED fails?

Ok, I have ensured that "SEARCH UNSEEN" is used for IMAP2 servers.

Also, I have also changed "NOT DELETED" to "UNDELETED" assuming that
"SEARCH UNSEEN UNDELETED" will be faster than "SEARCH UNSEEN NOT
DELETED". This syntax is acceptable as per IMAP4 and IMAP4r1 RFCs.

> > 2. Some servers do not support "SEARCH" at all. Here are some
> > references for that:
> > 
> > http://lists.ccil.org/pipermail/fetchmail-friends/2004-May/008675.html
> > http://lists.ccil.org/pipermail/fetchmail-friends/2005-January/009351.html
> > 
> > In this case, as a fallback, fetchmail should use something like:
> > 
> > FETCH 1:1000 FLAGS
> > 
> > and process all mails without \Seen as unseen.
> 
> Much appreciated. OK since it extends fetchmail's audience.

...

> > 3. The reply to "SEARCH UNSEEN" overflows fetchmail buffer when there
> > are more than 1860 unseen mails. fetchmail should do a range search:
> > 
> > SEARCH 1:1000 UNSEEN
> > SEARCH 1001:2000 UNSEEN
> > ...
> 
> Desirable bug fix.

...

> Looking forward to your patches!

Thanks a lot for that. I am submitting only one patch to fix all the
mentioned issues. It is not practical for me to submit separate
patches since all the issues are interlinked. Hope that that is
acceptable to you.

Here are the expected fallbacks this patch will do. This means that if
one search command fails, this patch will use the next command as per
the following list:

Case 1)
    no fetchall
    keep
    IMAP4 server or higher
    2000 mails in mailbox

IMAP> SEARCH 1:1000 UNSEEN UNDELETED
IMAP> SEARCH 1:1000 UNSEEN                   # fallback 1
IMAP> SEARCH UNSEEN                          # fallback 2
IMAP> FETCH 1:2000 FLAGS                     # fallback 3

Case 2)
    no fetchall
    keep
    IMAP4 server or higher
    300 mails in mailbox

IMAP> SEARCH UNSEEN UNDELETED
IMAP> SEARCH UNSEEN                          # fallback 1
IMAP> FETCH 1:300 FLAGS                      # fallback 2

Case 3)
    no fetchall
    no keep or IMAP2 server or both
    4000 mails in mailbox

IMAP> SEARCH 1:1000 UNSEEN
IMAP> SEARCH UNSEEN                          # fallback 1
IMAP> FETCH 1:4000 FLAGS                     # fallback 2

Case 4)
    no fetchall
    no keep or IMAP2 server or both
    500 mails in mailbox

IMAP> SEARCH UNSEEN
IMAP> FETCH 1:500 FLAGS                      # fallback 1

Also, is there an IMAP2 server available which can be used for testing
this patch?

-- 
Sunil Shetye.

Re: [fetchmail-devel] imap search improvements

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

Am 28.01.2010 10:04, schrieb Sunil Shetye:

> I am thinking of making some improvements to imap search in fetchmail.
> Please check which of these improvements are acceptable for fetchmail
> 6.3 series.

Dear Sunil,

great!  All proposed changes are acceptable, with comments below, and I
definitely trust your code.  All past contributions that passed through my hands
were of excellent quality, so thanks a bunch!

> ============================================================================================
> 1. In r3838, the "SEARCH UNSEEN" was changed to "SEARCH UNSEEN NOT
> DELETED". Some imap servers do not support such a complex search
> phrase. I could find only one reference for that:
> 
> http://lists.ccil.org/pipermail/fetchmail-friends/2004-June/008897.html
> 
> I propose that that change should be undone.
> 
> Note that "SEARCH UNSEEN NOT DELETED" gives different result from
> "SEARCH UNSEEN" only when
> 
> - another e-mail client has marked some mails for deletion without
>   seeing,
> - that e-mail client has not expunged the deleted mails, and
> - fetchmail is keeping mails (so that fetchmail also has not expunged
>   the deleted mails).
> 
> The comment in the code reads:
> 
> /* don't count deleted messages, in case user enabled keep last time */
> 
> This comment is incorrect. This is because fetchmail always marks the
> mail as \Seen irrespective of whether fetchmail deletes it or keeps
> it. So, that mail will not show up in the next "SEARCH UNSEEN".

Fixing comments is appreciated and always acceptable for supported versions.

The issue reported 5 years ago refers to a regression on IMAP2 servers, and a
regression fix is also always acceptable (though 6.2.X remains unsupported by
me, I'm not releasing another 6.2.X - the fix will go into 6.3.X then).

In the implementation of the fix, could you switch by protocol version to use
the "... NOT DELETED" form for newer servers (IMAP4r1, not sure if IMAP4 also
supports it), and the older "SEARCH UNSEEN" only in IMAP2?  That would give us
the best of both approaches -- or perhaps we could just fall back to SEARCH
UNSEEN if SEARCH UNSEEN NOT DELETED fails?

> ============================================================================================
> 2. Some servers do not support "SEARCH" at all. Here are some
> references for that:
> 
> http://lists.ccil.org/pipermail/fetchmail-friends/2004-May/008675.html
> http://lists.ccil.org/pipermail/fetchmail-friends/2005-January/009351.html
> 
> In this case, as a fallback, fetchmail should use something like:
> 
> FETCH 1:1000 FLAGS
> 
> and process all mails without \Seen as unseen.

Much appreciated. OK since it extends fetchmail's audience.

> ============================================================================================
> 3. The reply to "SEARCH UNSEEN" overflows fetchmail buffer when there
> are more than 1860 unseen mails. fetchmail should do a range search:
> 
> SEARCH 1:1000 UNSEEN
> SEARCH 1001:2000 UNSEEN
> ...

Desirable bug fix.

Hope that helps.

Looking forward to your patches!

Best regards
Matthias

[fetchmail-devel] imap search improvements

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

Hi Matthias,

I am thinking of making some improvements to imap search in fetchmail.
Please check which of these improvements are acceptable for fetchmail
6.3 series.

============================================================================================
1. In r3838, the "SEARCH UNSEEN" was changed to "SEARCH UNSEEN NOT
DELETED". Some imap servers do not support such a complex search
phrase. I could find only one reference for that:

http://lists.ccil.org/pipermail/fetchmail-friends/2004-June/008897.html

I propose that that change should be undone.

Note that "SEARCH UNSEEN NOT DELETED" gives different result from
"SEARCH UNSEEN" only when

- another e-mail client has marked some mails for deletion without
  seeing,
- that e-mail client has not expunged the deleted mails, and
- fetchmail is keeping mails (so that fetchmail also has not expunged
  the deleted mails).

The comment in the code reads:

/* don't count deleted messages, in case user enabled keep last time */

This comment is incorrect. This is because fetchmail always marks the
mail as \Seen irrespective of whether fetchmail deletes it or keeps
it. So, that mail will not show up in the next "SEARCH UNSEEN".


============================================================================================
2. Some servers do not support "SEARCH" at all. Here are some
references for that:

http://lists.ccil.org/pipermail/fetchmail-friends/2004-May/008675.html
http://lists.ccil.org/pipermail/fetchmail-friends/2005-January/009351.html

In this case, as a fallback, fetchmail should use something like:

FETCH 1:1000 FLAGS

and process all mails without \Seen as unseen.


============================================================================================
3. The reply to "SEARCH UNSEEN" overflows fetchmail buffer when there
are more than 1860 unseen mails. fetchmail should do a range search:

SEARCH 1:1000 UNSEEN
SEARCH 1001:2000 UNSEEN
...


============================================================================================

-- 
Sunil Shetye.