fetchmail-devel — Development related discussion

Re: [fetchmail-devel] Trouble parsing a particular fetchmailrc file: bison parser update?

[<JUA...@te...>]

Matthias Andree wrote:
> On Wed, 09 Jul 2008, JUA...@te... wrote:
> > Rob Funk wrote:
> > > Could you send us the fetchmailrc file and tell us specifically 
how 
> > it is
> > > being parsed incorrectly?
> > 
> > I am attaching a fetchmailrc file that is being parsed 
incorrectly.
> > 
> > Could someone run fetchmail on it to see that a username is being 
> > parsed incorrectly?
> > 
> > The username in question is being parsed as 'sername 
> > "aaaaaaaaaaaaa@aaaaaaaaaaaaa'
> 
> I can verify the problem, but I cannot currently narrow it down
> unfortunately - I can cut some lines from the file, but the 
remaining
> file is still way too large that I would want to observe the parser 
in
> debug mode.
> 
> Do you have a shorter file to exhibit the same problem?

It is quite difficult to trigger this bug.
If I change some lines the bug does not trigger.
I have got to the attached file that triggers the bug, but
if I remove the last line the same bug seems not to trigger.

> I can try to do some more experiments next week, but I'm not overly
> optimistic I'll be able to track and fix this.
> 
> It may be some arcane buffer boundary issue, and it may also be that
> we're inheriting a bison bug here.



Ahora también puedes acceder a tu correo Terra desde el móvil.
Infórmate pinchando aquí.

Re: [fetchmail-devel] Trouble parsing a particular fetchmailrc file: bison parser update?

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

On Wed, 09 Jul 2008, JUA...@te... wrote:

> Rob Funk wrote:
> > Could you send us the fetchmailrc file and tell us specifically how 
> it is
> > being parsed incorrectly?
> 
> I am attaching a fetchmailrc file that is being parsed incorrectly.
> 
> Could someone run fetchmail on it to see that a username is being 
> parsed incorrectly?
> 
> The username in question is being parsed as 'sername 
> "aaaaaaaaaaaaa@aaaaaaaaaaaaa'

I can verify the problem, but I cannot currently narrow it down
unfortunately - I can cut some lines from the file, but the remaining
file is still way too large that I would want to observe the parser in
debug mode.

Do you have a shorter file to exhibit the same problem?

I can try to do some more experiments next week, but I'm not overly
optimistic I'll be able to track and fix this.

It may be some arcane buffer boundary issue, and it may also be that
we're inheriting a bison bug here.

Sorry no positive reply yet.

-- 
Matthias Andree

Re: [fetchmail-devel] Trouble parsing a particular fetchmailrc file: bison parser update?

[<JUA...@te...>]

Rob Funk wrote:
> Could you send us the fetchmailrc file and tell us specifically how 
it is
> being parsed incorrectly?

I am attaching a fetchmailrc file that is being parsed incorrectly.

Could someone run fetchmail on it to see that a username is being 
parsed incorrectly?

The username in question is being parsed as 'sername 
"aaaaaaaaaaaaa@aaaaaaaaaaaaa'



Ahora también puedes acceder a tu correo Terra desde el móvil.
Infórmate pinchando aquí.

Re: [fetchmail-devel] documentation inconsistency - fetchmailrc permissions

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

Petr Uzel <pet...@su...> writes:

>> 6.3.9 will document 0700 but silently permit g+x for the nonce.
>
> Great. Do you have any idea when 6.3.9 will be out?

"soon" - given that I've no regression reports yet, I presume somewhen
July. Hopefully first half, but no promises.

fetchmail is currently strictly a spare-time one-man show.

HTH

-- 
Matthias Andree

Re: [fetchmail-devel] documentation inconsistency - fetchmailrc permissions

[Petr U. <pet...@su...>]

> > I'm not sure which maximum permissions are correct - whether 600 or 710.
> > (600 make better sense to me as I do not see any reason why fetchmailrc
> > should have execute permission).
>
> Thanks for pointing this out; "executable" makes some sense if you put
>
> #! /usr/bin/fetchmail -f
>
> as the first line of your rcfile.

Hmm, I didn't realize this....

> 6.3.9 will document 0700 but silently permit g+x for the nonce.

Great. Do you have any idea when 6.3.9 will be out?

Thanks,


-- 
Best regards / s pozdravem

Petr Uzel, Packages maintainer
---------------------------------------------------------------------
SUSE LINUX, s.r.o.                          e-mail: pet...@su...
Lihovarská 1060/12                          tel: +420 284 028 964
190 00 Prague 9                             fax: +420 284 028 951
Czech Republic                              http://www.suse.cz   

Re: [fetchmail-devel] documentation inconsistency - fetchmailrc permissions

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

Petr Uzel schrieb:
> Hello,
> 
> there seems to be a little incosistency between fetchmail manpage and the code 
> itself :
> 
> The manpage claims that fetchmailrc can not have greater permissions than 600 
> (u=rw) but fetchmail allows it to have 710 (u=rwx,g=x).
> 
> I'm not sure which maximum permissions are correct - whether 600 or 710. (600 
> make better sense to me as I do not see any reason why fetchmailrc should 
> have execute permission).

Thanks for pointing this out; "executable" makes some sense if you put

#! /usr/bin/fetchmail -f

as the first line of your rcfile.

I'll concede that 0710 isn't really sensible, since fetchmail needs to read
the file and would require g=rx if you're not the owner (user)... but I'm
not restricting it now for compatibility reasons.

6.3.9 will document 0700 but silently permit g+x for the nonce.

Fixed in SVN r5211.

The SVN repository is hosted at <http://mknod.org/svn/fetchmail/>, we're
currently on <http://mknod.org/svn/fetchmail/branches/BRANCH_6-3/>, in case
you want to pull a diff and patch.

Best regards
Matthias

[fetchmail-devel] documentation inconsistency - fetchmailrc permissions

[Petr U. <pet...@su...>]

Hello,

there seems to be a little incosistency between fetchmail manpage and the code 
itself :

The manpage claims that fetchmailrc can not have greater permissions than 600 
(u=rw) but fetchmail allows it to have 710 (u=rwx,g=x).

I'm not sure which maximum permissions are correct - whether 600 or 710. (600 
make better sense to me as I do not see any reason why fetchmailrc should 
have execute permission).


-- 
Best regards / s pozdravem

Petr Uzel, Packages maintainer
---------------------------------------------------------------------
SUSE LINUX, s.r.o.                          e-mail: pet...@su...
Lihovarská 1060/12                          tel: +420 284 028 964
190 00 Prague 9                             fax: +420 284 028 951
Czech Republic                              http://www.suse.cz   

Re: [fetchmail-devel] CRLF line terminators in contrib/delete-later

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

Petr Uzel schrieb am 2008-06-27:

> Hi,
> 
> is there any particular reason, why the contrib/delete-later script has CRLF 
> line terminators? (rpmlint does not like it :) )

Hi Petr,

I can see none, and will change that to LF for 6.3.9 release.
Thanks for reporting this.

(Fixed in SVN r5210.)

Best regards

-- 
Matthias Andree

Re: [fetchmail-devel] delete keeped message after X day

[PaulTT <pa...@gm...>]

On Thu, May 29, 2008 at 5:23 PM, Rob MacGregor <rob...@gm...> wrote:
> On Thu, May 29, 2008 at 4:02 PM, anouar boughariou
> <ano...@tu...> wrote:
>> Hi
>>
>> I use a keep parameter in my fetchmail and I want to delete only the last 5
>> day messages already delivered
>>
>> It's possible? How?
>
> http://www.fetchmail.info/fetchmail-FAQ.html#G5

you can try this patch, if you're using imap:
http://www.paultt.org/downloads/fetchmail/fetchmail_imap_days_ptt.diff

( http://www.paultt.org/downloads/index.html )

[fetchmail-devel] CRLF line terminators in contrib/delete-later

[Petr U. <pet...@su...>]

Hi,

is there any particular reason, why the contrib/delete-later script has CRLF 
line terminators? (rpmlint does not like it :) )


Thanks,

-- 
Best regards / s pozdravem

Petr Uzel, Packages maintainer
---------------------------------------------------------------------
SUSE LINUX, s.r.o.                          e-mail: pet...@su...
Lihovarská 1060/12                          tel: +420 284 028 964
190 00 Prague 9                             fax: +420 284 028 951
Czech Republic                              http://www.suse.cz   

[fetchmail-devel] fetchmail 6.3.9-rc2 release candidate

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

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

Greetings,

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

It collects three critical fixes, two of them security relevant, but
does not yet fix all pending known bugs - please check that this does
not introduce regressions over 6.3.8.

Note that -rc1 did not completely fix CVE-2008-2711. Thanks to Petr Uzel
for reporting this.

Happy fetching
Matthias

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Changes in 6.3.9-rc1 since 6.3.8:

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

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

fetchmail 6.3.9 (not yet released):

# SECURITY AND CRITICAL BUG FIXES:
* CVE-2007-4565: Denial of service: When fetchmail tries to inject a warning
  message it created itself, and the message is refused by the SMTP listener,
  fetchmail dereferences a NULL pointer and crashes. Report & fix by Earl Chew.
  Note while this is theoretically a remote denial of service attack vector,
  fetchmail by default talks SMTP to the localhost, so the overall risk is
  rather low.
  This bug was apparently introduced on 1998-11-27 when the bouncemail facility
  was modularized. The bug then made its appearance in fetchmail release 4.6.8.
  See also fetchmail-SA-2007-02.txt.
* CVE-2008-2711: Denial of service: When fetchmail logs data blobs
  (for instance, a To: header in -v -v verbose mode) in excess of 2048
  bytes, it will crash, because it hands an uninitialized argument
  pointer (not the format string though) to vsnprintf and reads a
  random memory location (it calls va_arg() too often without
  resetting it with va_start()). Based on a patch (BerliOS patch #2492)
  by Petr Uzel, fixes Novell Bug #354291.
  Note 6.3.9-rc1 did not completely fix this issue, so it was redrawn a few 
  hours after its release.
  See also fetchmail-SA-2008-01.txt.
* When expunging, mark the right messages as seen to avoid message loss in "keep
  flush" configurations.  Workaround for previous versions: "expunge 0".
  Report and patch by Alexander Cherepanov - thanks a lot, Berlios Bug #11797,
  "imap_mark_seen doesn't consider expunged messages".

# BUG FIXES:
* The configure script will additionally check for 'dn_skipname', to fix build
  failures with ?Clibc. The new check still recognizes the resolver libraries on
  Ubuntu 7.04, openSUSE 10.2, Solaris 8, NetBSD 4.0_BETA2 and FreeBSD 6.2.
  Fixes Gentoo bug #134187.
  NOTE: this is a bit of a hack, since we twist the HAVE_RES_SEARCH result, but
  res_search() and dn_skipname() are only used together and scheduled for
  removal in future versions, so this is probably fine.
* No longer complain about invalid sslproto "" when POP3 CAPA probe fails.
  Fixes Debian Bug#421446 (Holger Leskien), Novell Bug #247233 (Jon Nelson).
  Thanks to Matthias Strau? for a configuration to reproduce the issue.
* Allow .fetchmailrc and .fetchids to be symlinks, as the manpage does not
  document they aren't allowed - fixes Debian Bug #452907 (Roger Leigh).
  TOCTOU race persists.
* fetchmailconf quotes mailbox (folder) names when writing the configuration.
  Fixes BerliOS Bug #13207 (reported + fix suggested by Terry Brown).

# CHANGES:
* autoconf 2.60 is now required to build fetchmail; it uses
  AC_USE_SYSTEM_EXTENSIONS to replace AC_AIX, AC_MINIX, and the like.
* Removed dead FETCHMAIL_DEBUG code from fetchmail.h that was disabled by 
  default with no switches in configure to enable it. However, the macro would 
  have been prone to a symlink attack. Found by Nico Golde.
* Removed dead FORCE_STUFFING code from socket.c that was disabled by default
  with no switches in configure to enable it.
* Include the typedef for int16 in the #ifndef _AIX in smbencrypt.c (Peter
  O'Gorman)
* Correct check for u_int32_t in configure.ac (seems to be typedef'ed in
  namser.h on some platforms.) (Peter O'Gorman)
* In configure.ac change all CPFLAGS to CPPFLAGS, CEFLAGS to CFLAGS and LDEFLAGS
  to LDFLAGS otherwise the results of some tests (additional -L and -I flags) do
  not get used for later tests causing incorrect configure results. Makefile.am
  was also changed to reflect this. (Peter O'Gorman)
* m4/gethostbyname_r.m4 does AC_TRY_COMPILE, which unfortunately can pass even
  if there is no gethostbyname_r. Changed to AC_TRY_LINK. (Peter O'Gorman)
* Revise getnameinfo check to ensure NULL is defined and the result is properly
  evaluated, to avoid bogus results on for instance FreeBSD and redefinitions of
  NI_* at compile time. (Matthias Andree).
* __attribute__ ((unused)) is a gccism, removed from libesmtp/gethostbyname.c.
  (Peter O'Gorman)
* In KAME/getnameinfo.c it's best to use the correct argument to inet_ntoa.
  (Peter O'Gorman)
* In verbose mode, log if --check mode is enabled.
* Add sslcommonname option (rcfile and commandline) as a way to work around
  misconfigured upstream SSL servers that use the wrong certificate name. It
  specifies which CommonName fetchmail expects and logs. (Daniel Richard G.)

# DOCUMENTATION:
* Add fetchmail-SA-2007-02.txt and fetchmail-SA-2008-01.txt.
* Re-add two lines to the manual page that had accidentally become comments 
  to nroff. One was part of the --sslproto documentation, and one in the 
  "Awakening the background daemon" section.
* The manual page no longer asserts that .fetchids were for exclusive POP3 use, 
  since it is planned to use the file with IMAP4 later.
* Add grammar fixes from Dan Jacobson to fetchmail.man. Debian Bug #461642.
* The manual page now mentions that user descriptions need to come before user
  options. Reported by Francensco Pontort?, to fix Debian Bug #467010.
* The manual page no longer hints that multi-user declarations per server were
  only useful in daemon mode running as root, to avoid hinting people to doing
  that.
* Several manual page rcfile examples now include "ssl".
* The manual page hints that option arguments beginning with numbers can be
  enclosed in quotes.
* The manual page now mentions that the --logfile must already exist before
  fetchmail is run.
* The FAQ now recommends (#I9) not to use Google Mail for their disregard to the
  protocols they claim to support.

# TRANSLATION UPDATES:
* Polish (Jakub Bogusz)
* Japanese (Takeshi Hamasaki)
* Spanish (Javier Fern?ndez-Sanguino Pe?a, Matthias Andree)
* Vietnamese (Clytie Siddall)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFIYPRlvmGDOQUufZURAiHOAKCOyKvmoRE2cYjL74QpE3Hv1/wAEACfXXEM
a0HibzmCABixik9t4jrY3T0=
=Ir8O
-----END PGP SIGNATURE-----

[fetchmail-devel] fetchmail 6.3.9-rc1 release candidate

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

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

Greetings,

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

It collects three critical fixes, two of them security relevant, but
does not yet fix all pending known bugs - please check that this does
not introduce regressions over 6.3.8.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Changes in 6.3.9-rc1 since 6.3.8:

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

fetchmail 6.3.9 (not yet released):

# SECURITY FIX:
* CVE-2007-4565: Denial of service: When fetchmail tries to inject a warning
  message it created itself, and the message is refused by the SMTP listener,
  fetchmail dereferences a NULL pointer and crashes. Report & fix by Earl Chew.
  Note while this is theoretically a remote denial of service attack vector,
  fetchmail by default talks SMTP to the localhost, so the overall risk is
  rather low.
  This bug was apparently introduced on 1998-11-27 when the bouncemail facility
  was modularized. The bug then made its appearance in fetchmail release 4.6.8.
  See also fetchmail-SA-2007-02.txt.
* CVE-2008-2711: Denial of service: When fetchmail logs data blobs
  (for instance, a To: header in -v -v verbose mode) in excess of 2048
  bytes, it will crash, because it hands an uninitialized argument
  pointer (not the format string though) to vsnprintf and reads a
  random memory location (it calls va_arg() too often without
  resetting it with va_start()). Based on a patch (BerliOS patch #2492)
  by Petr Uzel, fixes Novell Bug #354291.
  See also fetchmail-SA-2008-01.txt.

# CRITICAL BUG FIX:
* When expunging, mark the right messages as seen to avoid message loss in "keep
  flush" configurations.  Workaround for previous versions: "expunge 0".
  Report and patch by Alexander Cherepanov - thanks a lot, Berlios Bug #11797,
  "imap_mark_seen doesn't consider expunged messages".

# BUG FIXES:
* The configure script will additionally check for 'dn_skipname', to fix build
  failures with µClibc. The new check still recognizes the resolver libraries on
  Ubuntu 7.04, openSUSE 10.2, Solaris 8, NetBSD 4.0_BETA2 and FreeBSD 6.2.
  Fixes Gentoo bug #134187.
  NOTE: this is a bit of a hack, since we twist the HAVE_RES_SEARCH result, but
  res_search() and dn_skipname() are only used together and scheduled for
  removal in future versions, so this is probably fine.
* No longer complain about invalid sslproto "" when POP3 CAPA probe fails.
  Fixes Debian Bug#421446 (Holger Leskien), Novell Bug #247233 (Jon Nelson).
  Thanks to Matthias Strauß for a configuration to reproduce the issue.
* Allow .fetchmailrc and .fetchids to be symlinks, as the manpage does not
  document they aren't allowed - fixes Debian Bug #452907 (Roger Leigh).
  TOCTOU race persists.
* fetchmailconf quotes mailbox (folder) names when writing the configuration.
  Fixes BerliOS Bug #13207 (reported + fix suggested by Terry Brown).

# CHANGES:
* autoconf 2.60 is now required to build fetchmail; it uses
  AC_USE_SYSTEM_EXTENSIONS to replace AC_AIX, AC_MINIX, and the like.
* Removed dead FETCHMAIL_DEBUG code from fetchmail.h that was disabled by 
  default with no switches in configure to enable it. However, the macro would 
  have been prone to a symlink attack. Found by Nico Golde.
* Removed dead FORCE_STUFFING code from socket.c that was disabled by default
  with no switches in configure to enable it.
* Include the typedef for int16 in the #ifndef _AIX in smbencrypt.c (Peter
  O'Gorman)
* Correct check for u_int32_t in configure.ac (seems to be typedef'ed in
  namser.h on some platforms.) (Peter O'Gorman)
* In configure.ac change all CPFLAGS to CPPFLAGS, CEFLAGS to CFLAGS and LDEFLAGS
  to LDFLAGS otherwise the results of some tests (additional -L and -I flags) do
  not get used for later tests causing incorrect configure results. Makefile.am
  was also changed to reflect this. (Peter O'Gorman)
* m4/gethostbyname_r.m4 does AC_TRY_COMPILE, which unfortunately can pass even
  if there is no gethostbyname_r. Changed to AC_TRY_LINK. (Peter O'Gorman)
* Revise getnameinfo check to ensure NULL is defined and the result is properly
  evaluated, to avoid bogus results on for instance FreeBSD and redefinitions of
  NI_* at compile time. (Matthias Andree).
* __attribute__ ((unused)) is a gccism, removed from libesmtp/gethostbyname.c.
  (Peter O'Gorman)
* In KAME/getnameinfo.c it's best to use the correct argument to inet_ntoa.
  (Peter O'Gorman)
* In verbose mode, log if --check mode is enabled.
* Add sslcommonname option (rcfile and commandline) as a way to work around
  misconfigured upstream SSL servers that use the wrong certificate name. It
  specifies which CommonName fetchmail expects and logs. (Daniel Richard G.)

# DOCUMENTATION:
* Add fetchmail-SA-2007-02.txt and fetchmail-SA-2008-01.txt.
* Re-add two lines to the manual page that had accidentally become comments 
  to nroff. One was part of the --sslproto documentation, and one in the 
  "Awakening the background daemon" section.
* The manual page no longer asserts that .fetchids were for exclusive POP3 use, 
  since it is planned to use the file with IMAP4 later.
* Add grammar fixes from Dan Jacobson to fetchmail.man. Debian Bug #461642.
* The manual page now mentions that user descriptions need to come before user
  options. Reported by Francensco Pontortì, to fix Debian Bug #467010.
* The manual page no longer hints that multi-user declarations per server were
  only useful in daemon mode running as root, to avoid hinting people to doing
  that.
* Several manual page rcfile examples now include "ssl".
* The manual page hints that option arguments beginning with numbers can be
  enclosed in quotes.
* The manual page now mentions that the --logfile must already exist before
  fetchmail is run.
* The FAQ now recommends (#I9) not to use Google Mail for their disregard to the
  protocols they claim to support.

# TRANSLATION UPDATES:
* Polish (Jakub Bogusz)
* Japanese (Takeshi Hamasaki)
* Spanish (Javier Fernández-Sanguino Peña, Matthias Andree)
* Vietnamese (Clytie Siddall)

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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)

iD8DBQFIYMGyvmGDOQUufZURAoXEAKCxK9DW7jBjlQTDCg8kRdKl3gu3SgCgzahk
Fd9lK/QWohcxbkVrdCLPoKg=
=XqTd
-----END PGP SIGNATURE-----

[fetchmail-devel] [Patch #2500] Limit downloads for some maximum load

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

Patch #2500 has been updated. 

Project: fetchmail
Category: None
Status: Open
Submitted by: jankratochvil
Assigned to : none
Summary: Limit downloads for some maximum load

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

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

[fetchmail-devel] [Feature #4192] deliver TO imap folder

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

Feature Request #4192, was updated on 2008-Jun-16 18:30
You can respond by visiting: 
http://developer.berlios.de/feature/?func=detailfeature&feature_id=4192&group_id=1824

Category: None
Status: Open
Priority: 5
Summary: deliver TO imap folder

By: anfi
Date: 2008-Jun-16 18:30

Message:
Logged In: YES 
user_id=46428
Browser: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.14) Gecko/20080404 Iceweasel/2.0.0.14 (Debian-2.0.0.14-2)

It would be nice to support fetched messages delivery
*TO* IMAP  folder (via IMAP protocol connection).

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

[fetchmail-devel] [Patch #2492] Fix segfault when retrieving mail with long 'To:' header

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

Patch #2492 has been updated. 

Project: fetchmail
Category: None
Status: Open
Submitted by: knot
Assigned to : none
Summary: Fix segfault when retrieving mail with long 'To:' header

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

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

Re: [fetchmail-devel] delete keeped message after X day

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

On Thu, May 29, 2008 at 4:02 PM, anouar boughariou
<ano...@tu...> wrote:
> Hi
>
> I use a keep parameter in my fetchmail and I want to delete only the last 5
> day messages already delivered
>
> It's possible? How?

http://www.fetchmail.info/fetchmail-FAQ.html#G5

-- 
 Please keep list traffic on the list.

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

[fetchmail-devel] delete keeped message after X day

[anouar b. <ano...@tu...>]

Hi

I use a keep parameter in my fetchmail and I want to delete only the last 5
day messages already delivered

It's possible? How?

thanks

Re: [fetchmail-devel] Add MAPI support to fetchmail

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

Jelmer Vernooij schrieb am 2008-04-30:

> Hi Matthias,
> 
> To quickly introduce myself: I'm one of the OpenChange developers and am
> mentoring Yangyan for the Summer of Code. 
> 
> Am Freitag, den 18.04.2008, 09:51 +0200 schrieb matthias.andreea:
> > The final issue I'd like to raise for this mail is that of licensing,
> > any third-party libraries should be GPLv2-compatible and
> > GPLv3-compatible and also AGPL-(Affero GPL) compatible so that I can
> > keep your parts should I rewrite major other parts of fetchmail and
> > maybe put them under the AGPL later on.
> > 
> > Hope that helps as an early starting point.
> OpenChange is licensed under GPLv3 or later; in other words,
> incompatible with GPLv2-only licensed code but compatible with "GPLv2 or
> later" licensed code. Is this a problem?
> 
> If it is, would it be acceptable if Yangyan's contributions were under
> these three licenses but not OpenChange? I imagine the support for MAPI
> would be a compile-time option anyway. Changing the OpenChange license
> is not really an option since it relies on Samba, which is GPLv3 or
> later as well.

Hi Jelmer, Yangyan, *,

I have contacted Carl Harris Jr (the popclient author, popclient is
fetchmail's predecessor, some lines of code remain in fetchmail) and
Eric S. Raymond (who extended and maintained fetchmail for a long time)
yesterday.

Carl considers GPLv3 compatible with his original distribution terms.

Eric lets me choose what suits the project best from "any version of
GPL", "GPL v2 or later", and "GPL v2 only", so I guess I'll turn it into
a "GPL v2, or, at your option, any later version of the GPL" for the
nonce, and later review if fetchmail as a whole should move on to GPL v3
or perhaps AGPL v3 - that would require a new license review.

I'll have to check if any code pieces remain that are GPLv2 only or
otherwise incompatible, or require consent of the authors to change to
"any later version" or similar; however, as I expect these to be minor,
I'm ready to drop or rewrite them if need be.

I expect the MAPI support to become part of a later fetchmail version
I'll dub 6.4 or 7.0 depending on the extent of other changes, so we have
the opportunity for a bigger cleanup anyways, and we should take it (for
instance, drop POP2 support).

WRT the MAPI code itself, I'd very much appreciate if it could be kept
in separate .c/.h/... files with as little changes to other files as
possible (for instance, don't hack too much on sink.c, but add a
sink-mapi.c file and just add the hooks to sink.c you need while
testing, and we'll in a team effort then split sink.c into sink.c,
sink-smtp.c (perhaps sink-lmtp.c), and sink-mda.c, and add your
sink-mapi.c.

HTH,

-- 
Matthias Andree

Re: [fetchmail-devel] Add MAPI support to fetchmail

[Jelmer V. <je...@op...>]

Hi Matthias,

To quickly introduce myself: I'm one of the OpenChange developers and am
mentoring Yangyan for the Summer of Code. 

Am Freitag, den 18.04.2008, 09:51 +0200 schrieb matthias.andreea:
> The final issue I'd like to raise for this mail is that of licensing,
> any third-party libraries should be GPLv2-compatible and
> GPLv3-compatible and also AGPL-(Affero GPL) compatible so that I can
> keep your parts should I rewrite major other parts of fetchmail and
> maybe put them under the AGPL later on.
> 
> Hope that helps as an early starting point.
OpenChange is licensed under GPLv3 or later; in other words,
incompatible with GPLv2-only licensed code but compatible with "GPLv2 or
later" licensed code. Is this a problem?

If it is, would it be acceptable if Yangyan's contributions were under
these three licenses but not OpenChange? I imagine the support for MAPI
would be a compile-time option anyway. Changing the OpenChange license
is not really an option since it relies on Samba, which is GPLv3 or
later as well.

Cheers,

Jelmer

Re: [fetchmail-devel] Fetchmail IMAP with FETCH x RFC822

[Georges-Etienne L. <le...@le...>]

>> Sorry, fetchmail cannot do this at the moment.
>>
>> Is there a way to tell Google not to violate the protocol?  Standards
>> are there for a purpose... please ask Google support to fix the  
>> server
>> software.
>
> After reviewing the situation, I've decided to amend to the FAQ:
> <http://www.fetchmail.info/fetchmail-FAQ.html#I9>

For your information, Google replied me:

On 25-Apr-08, at 6:39 PM, The Google Team wrote:
"We are aware of this problem, and our engineers are working  
diligently to
find a solution. We apologize for any inconvenience this issue may have
caused."

-- 
Georges-Etienne Legendre

Re: [fetchmail-devel] Fetchmail IMAP with FETCH x RFC822

[Georges-Etienne L. <le...@le...>]

On 24-Apr-08, at 4:32 AM, Matthias Andree wrote:

> On Thu, 24 Apr 2008, Matthias Andree wrote:
>
>> Georges-Etienne Legendre <le...@le...> writes:
>>
>>> When fetchmail fetch a message, it does this in 2 steps:
>>>
>>> 1) . FETCH x RFC822.HEADER
>>> 2) . FETCH x BODY.PEEK[TEXT]
>>>
>>> However, there is a problem with the Gmail IMAP implementation.  
>>> Gmail IMAP doesn't return a valid header if there is an encoded  
>>> field in the header.
>>> Instead, we have to use to get the whole mail in only one fetch:
>>>
>>> 1) . FETCH x RFC822
>>>
>>> The problem is documented here:
>>> http://groups.google.com/group/Gmail-Help-POP-and-IMAP-en/browse_thread/thread/06b49fde4a8dde08/d283b040984e4054
>>>
>>> Is there a way to tell to fetchmail to use the second approach?
>>
>> Sorry, fetchmail cannot do this at the moment.
>>
>> Is there a way to tell Google not to violate the protocol? Standards
>> are there for a purpose... please ask Google support to fix the  
>> server
>> software.

In fact, for this specific issue, I consider this as a bug in their  
IMAP implementation. For a strange reason they have decided to change  
the encoding from UTF-8 to ISO-8859-1 (bad thing, this doesn't follow  
standards), but have introduced a bug in doing so.

In any case, I think it would be great to support both way to fetch a  
message in IMAP (header+body, or header then body). I tried to  
enhanced fetchmail to add a configuration (like "single header-body  
fetch"). It looks like a bit more complicated and my modified version  
isn't able to completely fetch the message. It freeze.

Anyone willing to co-develop a patch for this feature? I don't think  
it's a big modification.
-- 
Georges-Etienne Legendre

Re: [fetchmail-devel] Fetchmail IMAP with FETCH x RFC822

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

On Thu, 24 Apr 2008, Matthias Andree wrote:

> Georges-Etienne Legendre <le...@le...> writes:
> 
> > When fetchmail fetch a message, it does this in 2 steps:
> >
> > 1) . FETCH x RFC822.HEADER
> > 2) . FETCH x BODY.PEEK[TEXT]
> >
> > However, there is a problem with the Gmail IMAP implementation. Gmail IMAP doesn't return a valid header if there is an encoded field in the header.
> > Instead, we have to use to get the whole mail in only one fetch: 
> >
> > 1) . FETCH x RFC822
> >
> > The problem is documented here:
> > http://groups.google.com/group/Gmail-Help-POP-and-IMAP-en/browse_thread/thread/06b49fde4a8dde08/d283b040984e4054
> >
> > Is there a way to tell to fetchmail to use the second approach?
> 
> Sorry, fetchmail cannot do this at the moment.
> 
> Is there a way to tell Google not to violate the protocol?  Standards
> are there for a purpose... please ask Google support to fix the server
> software.

After reviewing the situation, I've decided to amend to the FAQ:
<http://www.fetchmail.info/fetchmail-FAQ.html#I9>

-- 
Matthias Andree

Re: [fetchmail-devel] Fetchmail IMAP with FETCH x RFC822

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

Georges-Etienne Legendre <le...@le...> writes:

> When fetchmail fetch a message, it does this in 2 steps:
>
> 1) . FETCH x RFC822.HEADER
> 2) . FETCH x BODY.PEEK[TEXT]
>
> However, there is a problem with the Gmail IMAP implementation. Gmail IMAP doesn't return a valid header if there is an encoded field in the header.
> Instead, we have to use to get the whole mail in only one fetch: 
>
> 1) . FETCH x RFC822
>
> The problem is documented here:
> http://groups.google.com/group/Gmail-Help-POP-and-IMAP-en/browse_thread/thread/06b49fde4a8dde08/d283b040984e4054
>
> Is there a way to tell to fetchmail to use the second approach?

Sorry, fetchmail cannot do this at the moment.

Is there a way to tell Google not to violate the protocol?  Standards
are there for a purpose... please ask Google support to fix the server
software.

-- 
Matthias Andree

[fetchmail-devel] Fetchmail IMAP with FETCH x RFC822

[Georges-Etienne L. <le...@le...>]

Hi,

When fetchmail fetch a message, it does this in 2 steps:

1) . FETCH x RFC822.HEADER
2) . FETCH x BODY.PEEK[TEXT]

However, there is a problem with the Gmail IMAP implementation. Gmail  
IMAP doesn't return a valid header if there is an encoded field in the  
header. Instead, we have to use to get the whole mail in only one fetch:

1) . FETCH x RFC822

The problem is documented here:
http://groups.google.com/group/Gmail-Help-POP-and-IMAP-en/browse_thread/thread/06b49fde4a8dde08/d283b040984e4054

Is there a way to tell to fetchmail to use the second approach?

Thanks
-- 
Georges-Etienne Legendre

Re: [fetchmail-devel] Add MAPI support to fetchmail

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

"Yangyan Li" <yan...@gm...> writes:

> Hi Matthias,
>  
> http://lwn.net/Articles/192409/ tells us why it's useful for FLOSS to
> talk with MAPI, and OpenChange are working on two different aspects:
> provide interoperability with Exchange protocols and provide a
> transparent replacement to Microsoft Exchange Server with native
> Exchange protocols support and direct communication with Microsoft
> Outlook.
>  
> Fetchmail will be able to pull mail from Exchange, as well as push
> mail to Exhange, if MAPI support is added. It seems that there are few
> software under linux platform which support MAPI. One I know is
> Evolution, which provides MAPI support with a plugin developed by
> OpenChange. So it will be useful to add MAPI support to Fetchmail.
>  
> It's not decided whether I am the chosen one of this GSoC project, and
> this will be decided before April 21, 2008. However, I'd like to
> contribute to this project even if I'm not the chosen one.

Yangyan, back to technical issues, I think there are two places that
need to be changed.

For pulling mail, a new protocol ("MAPI" or "MSMAPI") would have to be
added, fetchmail's internal interface has a sort-of poor man's
object-oriented interface in C as there's a struct containing a set of
function pointers (look for struct method, for instance at the end of
imap.c).

For pushing mail over MAPI, sink.c would have to be amended to, and I'm
not so happy with the current shape of sink.c since it uses lots of
"if"s and indirections to determine if it's supposed to talk SMTP
(default), LMTP, or to an MDA.

I would very much like to see sink.c sort of "disentangled" first. There
is a reason why it is the way it's now, because it used to support (and
technically still does) "fallback", i. e. if the SMTP server goes down,
retry through an MDA, however I convinced Eric to switch this off by
default long ago, and before I slipped into becoming the de-facto
fetchmail maintainer. If we lose this "fallback" functionality along the
way of cleaning up sink.c, I don't mind.

Relevant parts to look at are said sink.c, driver.c, transact.c, and
possibly a few of the fetching protocols (imap.c, pop3.c), and a second
thought needs to be spent on the issue on who (server vs. computer
running fetchmail) will track what messages have been downloaded
yet. For POP3, both modes are possible (LAST vs. UIDL), but I do
recommend UIDL. IMAP does not yet support fetchmail-side tracking
(UID/UIDVALIDITY); while there's a patch on the BerliOS patch tracker,
it does not comprise UIDVALIDITY, so I haven't merged it yet.

Be sure to check todo.html and TODO.txt (these are not identical!) so
you know which context you're working in and what my short- and
long-term ideas are (I would not call them "plans" yet).

Feel free to ask further questions or describe how you'd like to
contribute. I think we can then branch fetchmail and negotiate
Subversion (SVN) access for you with Graham.

The final issue I'd like to raise for this mail is that of licensing,
any third-party libraries should be GPLv2-compatible and
GPLv3-compatible and also AGPL-(Affero GPL) compatible so that I can
keep your parts should I rewrite major other parts of fetchmail and
maybe put them under the AGPL later on.

Hope that helps as an early starting point.

Best regards,

-- 
Matthias Andree