fetchmail-devel — Development related discussion

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

[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.12.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] New Vietnamese PO file for 'fetchmail' (version 6.3.12)

[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.12.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 Czech PO file for 'fetchmail' (version 6.3.12)

[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.12.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 Japanese PO file for 'fetchmail' (version 6.3.12)

[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.12.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 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.12.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.12.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.12 regression/bug fix release available (STABLE)

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

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

Greetings,

I am announcing the release of fetchmail 6.3.12.  This new stable
version of fetchmail fixes a crash when 6.3.11 is run on SSL servers
without --verbose mode, and other bugs, and it updates translations.
See below for details.

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

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

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

# REGRESSION FIXES
* The CVS-2009-2666 fix in fetchmail release 6.3.11 caused a free() of
  unallocated memory on SSL connections, which caused crashes or program aborts
  on some systems (depending on how initialization and free() of unallocated
  memory is handled in compiler and libc).
  Workaround for older versions: run in verbose mode.
  Patch courtesy of Thomas Heinz, fixes Gentoo Bug #280760.
  This regression affected only the 6.3.11 release, but not the patch that was
  part of the security announcement fetchmail-SA-2009-01.

# BUG FIXES
* Fix error reporting for GSSAPI on Heimdal (h5l) Kerberos.
* Look for MD5_Init in libcrypto rather than libssl, fixes Gentoo Kerberos
  builds; fixes upstream parts of Gentoo Bugs #231400 and #185652, and fixes
  BerliOS Bug #16134.
* Report multiline SMTP errors properly, reported by Earl Chew; fixes Debian Bug
  #569899, reported by Akihiro Terasaki.
* Replace control characters in SMTP replies by '?'.
* Fetchmailconf: Fix descriptions for smtpaddress and smtpname options;
  smtpaddress is for RCPT TO, not MAIL FROM. Found by Gerard Seibert.

# TRANSLATION UPDATES AND ADDITIONS (ordered by language name):
* [ca]    Catalan (Ernest Adrogué Calveras)
* [zh_CN] Chinese/Simplified (Ji ZhengYu)
* [cs]    Czech (Petr Pisar)
* [ja]    Japanese (Takeshi Hamasaki)
* [pl]    Polish (Jakub Bogusz)
* [es]    Spanish/Castilian (Francisco Molinero)
* [vi]    Vietnamese (Clytie Siddall)

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

iEYEARECAAYFAkrKUw8ACgkQvmGDOQUufZXSpgCg8C5DoVRWN4RDLYBp+LLGXnRE
c9kAnAuxK1zWAbf2guw3VtOjIllNCTjG
=IQDb
-----END PGP SIGNATURE-----

[fetchmail-devel] [Feature #4790] apply antispam to RCPT TO

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

Feature Request #4790, was updated on 2009-Sep-25 10:41
You can respond by visiting: 
http://developer.berlios.de/feature/?func=detailfeature&feature_id=4790&group_id=1824

Category: None
Status: Open
Priority: 5
Summary: apply antispam to RCPT TO

By: seanster
Date: 2009-Sep-25 10:41

Message:
Logged In: YES 
user_id=53384
Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090923 (.NET CLR 3.5.30729)

It appears that the antispam option only applies to
results from MAIL FROM.

It would be desirable to have it also apply to RCPT TO:

The reasoning here is that the spam decision is not
completed until I know who you want to send to.
For example I may have a postmaster account that allows
non-resolvable domains and allows me to help
troubleshoot nameserver problems. All other accounts on
my server reject non-resolvable domains.

I can't imagine I am special in any way.

Consider this smtp exchange between fetchmail and my
local sendmail:

SMTP> MAIL FROM:<tenak@123-4f47685e57d> BODY=7BIT SIZE=1459
SMTP< 250 2.1.0 <tenak@123-4f47685e57d>... Sender ok
SMTP> RCPT TO:<a_valid_user@localhost>
SMTP< 553 5.1.8 <a_valid_user@localhost>... Domain of
sender address tenak@123-4f47685e57d does not exist

As you can see, I'm reporting that I don't like the
sender, but only after they tell me who they want to
send to.

At the moment, to force cleaning out those dead
messages from my pop accounts, I use the "set no
softbounce" option. That's really dangerous as there's
other possible permanent errors where I would choose to
keep the mail in the pop account. Using antispam would
allow me to choose.

I'm not a fetchmail or sendmail guru. I realise I could
just be doing something wrong. I'm happy to discuss
this with anyone.


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

[fetchmail-devel] New Chinese (simplified) PO file for 'fetchmail' (version 6.3.11)

[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 Chinese (simplified) team of translators.  The file is available at:

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

(This file, 'fetchmail-6.3.11.zh_CN.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 Vietnamese PO file for 'fetchmail' (version 6.3.11)

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

Re: [fetchmail-devel] [FYI patch] Fix DNS resolution

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

Am 03.09.2009, 14:13 Uhr, schrieb Thomas Jarosch  
<tho...@in...>:

> I just upgraded from fetchmail 6.3.9 to fetchmail 6.3.11
> and quickly noticed DNS resolution stopped working for me.
>
> This system uses kernel 2.6.30.5 without IPv6 support, bind-9.6.1
> and an ancient glibc 2.1.3. I had to revert the recent
> "hints.ai_flags |= AI_ADDRCONFIG" change to get it back working.
>
> I've attached my patch just in case someone else is affected, too.
> Though I guess this is an issue of the ancient glibc version.

Hi Thomas,

I don't mean to support glibc 2.1.3. It didn't properly support IPv6, and  
it if ships broken implementations of standards interfaces (IEEE Std  
1003.1-2001) such as getaddrinfo(), there isn't much an application can do.

This AI_ADDRCONFIG change fixes real-world issues and has been in Red  
Hat's packages for a long time.

Sorry.

-- 
Matthias Andree

[fetchmail-devel] [FYI patch] Fix DNS resolution

[Thomas J. <tho...@in...>]

Hello,

I just upgraded from fetchmail 6.3.9 to fetchmail 6.3.11
and quickly noticed DNS resolution stopped working for me.

This system uses kernel 2.6.30.5 without IPv6 support, bind-9.6.1
and an ancient glibc 2.1.3. I had to revert the recent
"hints.ai_flags |= AI_ADDRCONFIG" change to get it back working.

I've attached my patch just in case someone else is affected, too.
Though I guess this is an issue of the ancient glibc version.

Cheers,
Thomas

Re: [fetchmail-devel] mapi again

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

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

Matthias Andree wrote:
>>> strace or truss could help. You could also grep "ps ax" or "ps -ef" 
>>> output
>> good idea - will do next time that happens.
>> weren't there some performance monitor for linux? three or four letters
>> that was... oh i cannot remember the name :)
>
> Hm. top? But that doesn't show leaks. There are several memory leak 
> checkers around, Google should come up with things like memprof,
valgrind, 
> an efence spinoff with a new name that I forgot.
>
If you want to find memory leaks, please use the latest versions of
the openchange libraries. A lot of memory leaks have been fixed recently.

Cheers,

Jelmer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10rc1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJKnrAxAAoJEACAbyvXKaRXkxQP+wSbH6mlKk3S6v3+IyHPbJtt
p1+gNgeD2fMLMIPmA8k/CtSa/JkFh30pmpiMPOhqbPMROUl612c2cMwaproc/lw/
WfId6kflWCZBmgyMSYssJeJyrgm19sKJC3uhw2teAxySqCyr50OIYrQ8/F8kVAbm
3IX2wBq6sbJBjLYgD2inWjvNCsKSxmbVc2Bte2CIWjs6Q6/iVAMhb+5Q5ac/I5bw
LgdFCKEG4ffNaRgQ6jr3iEDfZtPyjzxgtmnL++d0oeeKlVZ21doUiLpYJWC65QHe
lq5wRTdNFdv2s1KZPFzvZ73angjf2nEJHa6G245alwpZFBP6QyvgKkj9aap3QAei
n9iGFKYtLAEoGcOUsOIztXSvqWjQ5z4N0qzfNLO1x6/xTO7ysApr0xi6/Fv/cJJy
9yUg7Gkvn+PDKx9BMyKY8/DRtPi1D59Wd7VjosyFu3KO3zmdmoFPcSaHipMOy810
mszw/Rw9e5yNwFovpxwOzLNpB6lQNfkUdObUmUkq5x7qTzmd2aeTAwcn3Oxwdfb7
1AzKDljPUOJO2Jlk88vDJiFe3hyIxTpbNM4kgumkSozA/i1l9dEp5HZvuAgjrZIp
LDyQYHJlc0OVOdVFeBGo41aWuDilHgFswJ4ENv/EeO5r6uBhhmAbHr4fFrJXnRf+
DzTx3iQ2G3UO2KwcRvhb
=xx+P
-----END PGP SIGNATURE-----

Re: [fetchmail-devel] mapi again

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

Am 02.09.2009, 19:50 Uhr, schrieb Jelmer Vernooij <je...@op...>:

> If you want to find memory leaks, please use the latest versions of
> the openchange libraries. A lot of memory leaks have been fixed recently.

That's good news. Thanks to all those involved in the plugging.

-- 
Matthias Andree

Re: [fetchmail-devel] mapi again

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

Am 02.09.2009, 10:25 Uhr, schrieb mojmir svoboda  
<moj...@2k...>:

> good morning Matthias,
>
> * mat...@gm... <mat...@gm...> [2009-08-28 06:15:43  
> +0000]:
>
>> * Don't introduce security holes, avoid static buffers
>
> oh i must read some secure programming stuff, i was never involved :)
> by avoiding static buffers (local? global ones?) you mean allocate
> every buffer on heap?

Most importantly: don't trust data you got over the network, through  
openchange or any other library. Don't assume data makes sense or has  
sensible lenghts, or integers are positive or make sense. Sanity check  
array indexes that they aren't out of bounds. Make sure string copies are  
always length limited or that you the output is allocated properly. Do not  
use functions that copy arbitrary length data. Note that strncpy has  
awkward implications about the NUL byte termination, but you can use  
strlcpy and strlcat instead.

>> > 4. mapi todo
>> > - threading of messages does not work
>>
>> Is the cause known yet? Incomplete headers, such as In-Reply-To: or
>> References:?
>
> yes, only very few fields from the whole header is passed to mda. i have
> to add the other fields, the problem is which ones, mapi has cca 1000 of
> these tags :) i'll talk with openchange people about this.

:-( That's tough luck. I had hoped that there were some function to fetch  
internet headers fully (Outlook 2003 can do that, so I'd assume Exchange  
can deliver that - but I may be wrong and Outlook just emulates it).

>
>> > - when > 1000 messages, fetchmail says it cannot open MDA
>> > 	  report(stderr, GT_("MDA open failed\n"));
>>
>> Try running with -vvv and see if you still get the "about to deliver
>> with:" message, and please show it to me.
>
> oka, next time, i had to run outlook and flush everything so every time
> that happens i loose some of messages.
>
>> Can I also see your mda option's argument?
>
> mda "procmail -d x"

Hm. Should be safe - but make sure that "x" is sensible - procmail tries  
to setuid to x, and if x doesn't exist, there's no way it will succeed --  
the exact implications depend on whether fetchmail is in multidrop or  
singledrop mode.

>> strace or truss could help. You could also grep "ps ax" or "ps -ef"  
>> output
>
> good idea - will do next time that happens.
> weren't there some performance monitor for linux? three or four letters
> that was... oh i cannot remember the name :)

Hm. top? But that doesn't show leaks. There are several memory leak  
checkers around, Google should come up with things like memprof, valgrind,  
an efence spinoff with a new name that I forgot.

HTH

Best regards

-- 
Matthias Andree

Re: [fetchmail-devel] mapi again

[mojmir s. <moj...@2k...>]

good morning Matthias,

* mat...@gm... <mat...@gm...> [2009-08-28 06:15:43 +0000]:

> * Don't introduce security holes, avoid static buffers

oh i must read some secure programming stuff, i was never involved :)
by avoiding static buffers (local? global ones?) you mean allocate
every buffer on heap?

> > 2. mapi
> > /O=TAKE-TWOINTERACTIVE/OU=2KGB/CN=RECIPIENTS/CN?A....@2k...rp
> 
> Looks like ITU-T X.500 series stuff, which isn't overly weird, it's just
> that you're usually interested in the CN field (common name). Depending on
> how openMAPI gets this information to you, take care of escaping and
> continuation lines. LDIF for instance has rather unusual (in my personal
> perspetion) line continuation format... just chop, insert LF and blank...

oka, will try

> > 4. mapi todo
> > - threading of messages does not work
> 
> Is the cause known yet? Incomplete headers, such as In-Reply-To: or
> References:?

yes, only very few fields from the whole header is passed to mda. i have
to add the other fields, the problem is which ones, mapi has cca 1000 of
these tags :) i'll talk with openchange people about this.

> > - when > 1000 messages, fetchmail says it cannot open MDA
> > 	  report(stderr, GT_("MDA open failed\n"));
> 
> Try running with -vvv and see if you still get the "about to deliver
> with:" message, and please show it to me.

oka, next time, i had to run outlook and flush everything so every time
that happens i loose some of messages.

> Can I also see your mda option's argument?

mda "procmail -d x"

> In doubt, report the usual stuff I ask users to report,
> http://www.fetchmail.info/fetchmail-FAQ.html#G3

gentoo, i686-pc-linux-gnu
gcc version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5)
mda = procmail v3.22 2001/09/10
using fetchmail -kvvv options. -F for separate flush

more info next time i'll investigate that behaviour.

> WRT descriptor leaks: Try "lsof -c fetchmail" in a separate console while

i did that in fact and according to lsof there seems not to be descriptor leak.

> strace or truss could help. You could also grep "ps ax" or "ps -ef" output

good idea - will do next time that happens.
weren't there some performance monitor for linux? three or four letters
that was... oh i cannot remember the name :)

> <http://www.fetchmail.info/fetchmail-FAQ.html#S2> - does it help to fiddle
> with the Exchange registry?

ee, i do not have access to exchange server as i am trying it on company's mail
server. well these messages seem non fatal, so i'd postpone this too.


i have to hurry back to work so bye and many thanks for your responses,
mojmir

Re: [fetchmail-devel] mapi again

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

Hi Mojmir,

and thanks for your continued care of the MAPI function.

> hello again,
> i have few things on my mind:
>
> 1. portability of fetchmail
> - what all platforms do you support/want to support?
> 	(i've seen some linuxes, bsds, are there more?)

I usually care about Linux (Debian, Fedora, openSUSE), FreeBSD and  
Solaris. Not breaking Cygwin and the other mainstream BSDs would be nice.  
I don't care if you break BeOS or EMX or if Red Hat Linux 5.2 won't work.

I think current versions of Linux, BSD, Solaris/openSolaris (as  
representative for the SysV systems), Cygwin. That should cover the  
important ones. If obscure or obsolete OSes break with MAPI support, never  
mind.

> - same about compilers?
> 	(gcc.. what about the bunch of others?)

GCC 3.4 and 4.3 are a must, 3.3 - 4.4 would be nice. In doubt, try  
"-pedantic" :)

> - are there any restrictions about C language used in fetchmail?
> 	(variadic macros for example etc)

I'm undecided, I don't want to break older systems deliberately, so avoid  
if you can for now.
If it's used only for MAPI, use whatever suits your purpose. Note that  
macros defeat type checking, so use functions if you can.

> - any crucial advice concerning fetchmail development?

* Don't introduce security holes, avoid static buffers, and avoid  
unbounded access (array subscripts/indexes, non-length-limiting string  
functions) at all cost, particularly for statically sized buffers these  
are a must.

* Where it makes sense to translate strings, please mark them  
translatable, and - I probably don't need to tell you - if there are  
various plural forms, please use the NGT_() macro, not just GT_(). Please  
don't assemble translated strings with fragments of English phrases.

> 2. mapi
> i have found the problem with the overwrite of address, but
> have no fix yet. the problem occurs when value of tag
> PR_SENT_REPRESENTING_NAME does not contain FQDN (fully qualified
> domain name... is that the name?), because it gets scrambled
> by the reply_hack function from transact.c
>
> this can be fixed by using PR_SENDER_EMAIL_ADDRESS, but it's
> not perfect, since it contains weird stuff like
>
> 	From:  
> /O=TAKE-TWOINTERACTIVE/OU=2KGB/CN=RECIPIENTS/CN=AA...@2k...rp

Looks like ITU-T X.500 series stuff, which isn't overly weird, it's just  
that you're usually interested in the CN field (common name). Depending on  
how openMAPI gets this information to you, take care of escaping and  
continuation lines. LDIF for instance has rather unusual (in my personal  
perspetion) line continuation format... just chop, insert LF and blank...

> 3. documentation for mapi...
> ...would be great. do you have any, please?

I don't - OpenChange perhaps? Otherwise ask Jelmer Vernooi if he wants to  
help (he mentored Yang-Yan Li last year) or the openchange lists.

> 4. mapi todo
> - the problem above
> - AND the same problem applying to To: and Cc: fields
> - threading of messages does not work

Is the cause known yet? Incomplete headers, such as In-Reply-To: or  
References:?

> - valgrind reporting some memory stuff (reads beyond etc)

If they're in OpenSSL, disregard. If they're in OpenChange, they'll  
probably want to know...

> - fetching messages is quite slow

Too bad. I'd say postpone this. If it works slowly, than that's better  
than "not at all" :)

> - when > 1000 messages, fetchmail says it cannot open MDA
>   with some IO error. it fails in sink.c:open_mda_sink after
>   the popen.
> 	  report(stderr, GT_("MDA open failed\n"));
>   perhaps some descriptor leak? do you have any ideas, please?

Try running with -vvv and see if you still get the "about to deliver  
with:" message, and please show it to me.
Can I also see your mda option's argument? In doubt, report the usual  
stuff I ask users to report,  
http://www.fetchmail.info/fetchmail-FAQ.html#G3

WRT descriptor leaks: Try "lsof -c fetchmail" in a separate console while  
fetchmail is fetching and short before it fails, i. e. after say 500 or  
700 messages. If it's a descriptor leak, you'll get to know. Otherwise,  
strace or truss could help. You could also grep "ps ax" or "ps -ef" output  
for hints of process table exhaustion (grep for your MDA software).

> - flushing messages is also quite slow
> - messages like:
> 	- xxx:54 was not the expected length (1032 actual != 4863 expected)

Probably similar artifacts to  
<http://www.fetchmail.info/fetchmail-FAQ.html#S2> - does it help to fiddle  
with the Exchange registry?

HTH

Best regards
Matthias

-- 
Matthias Andree

[fetchmail-devel] mapi again

[mojmir s. <moj...@2k...>]

hello again,
i have few things on my mind:

1. portability of fetchmail
- what all platforms do you support/want to support?
	(i've seen some linuxes, bsds, are there more?)
- same about compilers?
	(gcc.. what about the bunch of others?)
- are there any restrictions about C language used in fetchmail?
	(variadic macros for example etc)
- any crucial advice concerning fetchmail development?

2. mapi
i have found the problem with the overwrite of address, but
have no fix yet. the problem occurs when value of tag
PR_SENT_REPRESENTING_NAME does not contain FQDN (fully qualified
domain name... is that the name?), because it gets scrambled
by the reply_hack function from transact.c

this can be fixed by using PR_SENDER_EMAIL_ADDRESS, but it's
not perfect, since it contains weird stuff like 

	From: /O=TAKE-TWOINTERACTIVE/OU=2KGB/CN=RECIPIENTS/CN=AA...@2k...rp

so ideally the solution would be like:
  if (PR_SENT_REPRESENTING_NAME is in form foo@FQDN)
	  use PR_SENT_REPRESENTING_NAME
  else
	  use PR_SENDER_EMAIL_ADDRESS;

perhaps there's some flag in the mapi protocol but i can only
guess... so:

3. documentation for mapi...
...would be great. do you have any, please?

4. mapi todo
- the problem above
- AND the same problem applying to To: and Cc: fields
- threading of messages does not work
- valgrind reporting some memory stuff (reads beyond etc)
- fetching messages is quite slow
- when > 1000 messages, fetchmail says it cannot open MDA
  with some IO error. it fails in sink.c:open_mda_sink after
  the popen.
	  report(stderr, GT_("MDA open failed\n"));
  perhaps some descriptor leak? do you have any ideas, please?
- flushing messages is also quite slow
- messages like:
	- xxx:54 was not the expected length (1032 actual != 4863 expected)


kind regards,
mojmir

[fetchmail-devel] [Bug #16134] Incorrect library check in configure

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

Bug #16134, was updated on 2009-Aug-13 17:00
Here is a current snapshot of the bug.

Project: Community Fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Submitted by: voidmage
Assigned to : m-a
Summary: Incorrect library check in configure

Details: This is a followup of very old Gentoo bugs: 231400 and 185652.
It's a -Wl,--as-needed problem.
Most of it is a Gentoo only problem, except for two things:
- MD5_Init is in libcrypto, not libssl, so the check in configure.ac
is incorrect (well, OK, it's not documented that well,
which functions are in libssl and which in libcrypto)
- why it did work with that check removed -
is that check not really needed ?

Right now (since 6.3.9 at least), only thing I needed to do
to make things work, were changing "ssl" to "crypto" in
that AC_CHECK_LIB check.

In one of Flameeyes' blog posts it said that somewhere after
binutils 2.19, they've changed the behavior, so perhaps
even current state will work, but it's not that way now.

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

[fetchmail-devel] [Bug #16172] Fetchmail eats mail when unable to connect to SMTP

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

Bug #16172, was updated on 2009-Aug-24 10:38
Here is a current snapshot of the bug.

Project: Community Fetchmail
Category: None
Status: Open
Resolution: Works For Me
Bug Group: None
Priority: 7
Submitted by: bennovdbogaard
Assigned to : m-a
Summary: Fetchmail eats mail when unable to connect to SMTP

Details: Hello everyone,

I use fetchmail in various production environments and I discovered some unwanted behaviour.

After fetchmail fetches mail from a pop mail server it removes messages after they are retrieved. But if the SMTP to deliver these messages to isn't available, it drops the messages and gives up instantly.

Could this behaviour be altered by first checking if the SMTP server is reachable and then decide to fetch the messages?

Yours,
Benno van den Bogaard <be...@ho...>

Follow-Ups:

Date: 2009-Aug-24 14:05
By: m-a

Comment:
Please prove through complete logs that fetchmail 6.3.10 or 6.3.11 loses mail and to show it's not a server fault (some servers are known to delete mail after retrieval even if the client hasn't requested deletion; also, some may make deletes effective before QUIT).

See http://www.fetchmail.info/fetchmail-FAQ.html#G3 for a list of pieces of information that we need to debug the issue.

Fetchmail has been designed to NOT delete messages from the server before it has successfully delivered them.

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

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

[fetchmail-devel] [Bug #16172] Fetchmail eats mail when unable to connect to SMTP

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

Bug #16172, was updated on 2009-Aug-24 10:38
Here is a current snapshot of the bug.

Project: Community Fetchmail
Category: None
Status: Open
Resolution: Works For Me
Bug Group: None
Priority: 7
Submitted by: bennovdbogaard
Assigned to : m-a
Summary: Fetchmail eats mail when unable to connect to SMTP

Details: Hello everyone,

I use fetchmail in various production environments and I discovered some unwanted behaviour.

After fetchmail fetches mail from a pop mail server it removes messages after they are retrieved. But if the SMTP to deliver these messages to isn't available, it drops the messages and gives up instantly.

Could this behaviour be altered by first checking if the SMTP server is reachable and then decide to fetch the messages?

Yours,
Benno van den Bogaard <be...@ho...>

Follow-Ups:

Date: 2009-Aug-24 14:05
By: m-a

Comment:
Please prove through complete logs that fetchmail 6.3.10 or 6.3.11 loses mail and to show it's not a server fault (some servers are known to delete mail after retrieval even if the client hasn't requested deletion; also, some may make deletes effective before QUIT).

See http://www.fetchmail.info/fetchmail-FAQ.html#G3 for a list of pieces of information that we need to debug the issue.

Fetchmail has been designed to NOT delete messages from the server before it has successfully delivered them.

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

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

[fetchmail-devel] [Bug #16172] Fetchmail eats mail when unable to connect to SMTP

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

Bug #16172, was updated on 2009-Aug-24 10:38
Here is a current snapshot of the bug.

Project: Community Fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: bennovdbogaard
Assigned to : m-a
Summary: Fetchmail eats mail when unable to connect to SMTP

Details: Hello everyone,

I use fetchmail in various production environments and I discovered some unwanted behaviour.

After fetchmail fetches mail from a pop mail server it removes messages after they are retrieved. But if the SMTP to deliver these messages to isn't available, it drops the messages and gives up instantly.

Could this behaviour be altered by first checking if the SMTP server is reachable and then decide to fetch the messages?

Yours,
Benno van den Bogaard <be...@ho...>

Follow-Ups:

Date: 2009-Aug-24 14:05
By: m-a

Comment:
Please prove through complete logs that fetchmail 6.3.10 or 6.3.11 loses mail and to show it's not a server fault (some servers are known to delete mail after retrieval even if the client hasn't requested deletion; also, some may make deletes effective before QUIT).

See http://www.fetchmail.info/fetchmail-FAQ.html#G3 for a list of pieces of information that we need to debug the issue.

Fetchmail has been designed to NOT delete messages from the server before it has successfully delivered them.

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

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

[fetchmail-devel] [Bug #16172] Fetchmail eats mail when unable to connect to SMTP

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

Bug #16172, was updated on 2009-Aug-24 10:38
Here is a current snapshot of the bug.

Project: Community Fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: bennovdbogaard
Assigned to : none
Summary: Fetchmail eats mail when unable to connect to SMTP

Details: Hello everyone,

I use fetchmail in various production environments and I discovered some unwanted behaviour.

After fetchmail fetches mail from a pop mail server it removes messages after they are retrieved. But if the SMTP to deliver these messages to isn't available, it drops the messages and gives up instantly.

Could this behaviour be altered by first checking if the SMTP server is reachable and then decide to fetch the messages?

Yours,
Benno van den Bogaard <be...@ho...>

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

[fetchmail-devel] [Bug #16171] Bad xfree() call..

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

Bug #16171, was updated on 2009-Aug-24 04:27
Here is a current snapshot of the bug.

Project: Community Fetchmail
Category: None
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: marka
Assigned to : none
Summary: Bad xfree() call..

Details: --- socket.c.orig       2009-08-06 09:15:52.000000000 +1000
+++ socket.c    2009-08-24 11:59:30.000000000 +1000
@@ -628,9 +628,10 @@
                                report(stdout, GT_("Unknown Issuer CommonName\n"));
                }
                if ((i = X509_NAME_get_text_by_NID(subj, NID_commonName, buf, sizeof(buf))) != -1) {
-                       if (outlevel >= O_VERBOSE)
+                       if (outlevel >= O_VERBOSE) {
                                report(stdout, GT_("Server CommonName: %s\n"), (tt = sdump(buf, i)));
-                       xfree(tt);
+                               xfree(tt);
+                       }
                        if ((size_t)i >= sizeof(buf) - 1) {
                                /* Possible truncation. In this case, this is a DNS name, so this
                                 * is really bad. We do not tolerate this even in the non-strict case. */


Follow-Ups:

Date: 2009-Aug-24 09:55
By: m-a

Comment:
Thanks. This is already fixed and announced:
https://developer.berlios.de/project/shownotes.php?group_id=1824&release_id=16574
-------------------------------------------------------

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

[fetchmail-devel] [Bug #16171] Bad xfree() call..

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

Bug #16171, was updated on 2009-Aug-24 12:27
Here is a current snapshot of the bug.

Project: Community Fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: marka
Assigned to : none
Summary: Bad xfree() call..

Details: --- socket.c.orig       2009-08-06 09:15:52.000000000 +1000
+++ socket.c    2009-08-24 11:59:30.000000000 +1000
@@ -628,9 +628,10 @@
                                report(stdout, GT_("Unknown Issuer CommonName\n"));
                }
                if ((i = X509_NAME_get_text_by_NID(subj, NID_commonName, buf, sizeof(buf))) != -1) {
-                       if (outlevel >= O_VERBOSE)
+                       if (outlevel >= O_VERBOSE) {
                                report(stdout, GT_("Server CommonName: %s\n"), (tt = sdump(buf, i)));
-                       xfree(tt);
+                               xfree(tt);
+                       }
                        if ((size_t)i >= sizeof(buf) - 1) {
                                /* Possible truncation. In this case, this is a DNS name, so this
                                 * is really bad. We do not tolerate this even in the non-strict case. */


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

Re: [fetchmail-devel] BerliOS/mailing list companion web site X.509 certificates (was: Multiple sslfingerprint options and digests)

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

Am 11.08.2009, 23:44 Uhr, schrieb grarpamp <gra...@gm...>:

> Note3: The lists.berlios.de cert is expired, and MD5, though that
> doesn't matter :) The Berlios_CA cert may be self-signed.

Berlios's certificate management is a mystery to me (to spare other  
rants), and I can't seem to get a hold of an admin who could provide me  
with the CA's root certificate or to be bothered about expired or  
non-matching certficiates.

If anyone has a direct link to prod them to proper certificate management  
practices, that would be quite welcome...

-- 
Matthias Andree