fetchmail-devel — Development related discussion

[fetchmail-devel] mapi - openchange-tools.c patch

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

attached you will find patch to patch openchange-tools.c
the error was in bad type of read_size (u32, libmapi requires
u16).

now it works at least for text/plain messages (tested). there
is probably another bug in saving text/html message because
it results in zero length.

hth,
mojmir

Re: [fetchmail-devel] fetchmail and mapi II

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

* Mat...@2k...rp <Mat...@2k...rp> [2009-06-16 14:11:37 +0000]:

> > as a hotfix i simply allocated lot of memory and removed the loop that
> > did nothing. i assume you do not want that kind of solution (and neither
> > do i.. in long term)
> 
> Ah, ok.

in attachment there is a patch fixing this (hopefuly) correctly.  still,
the postscript attachment i sent myself got little bit scrambled
(periodically at buffer boundaries). may be bug in stream, may be bug in
ldb_base64_encode.

btw: ldb_base64_encode can be removed from the source file mapi.c, as it
is already present in samba4.

> >> > 6. \r characters and = spread all around in mail body
> This looks like quoted printable encoding to me. hex is likely (i. e. I

i confirm. this seems to be hardcoded in mapi.c
perhaps there should be an option specifying output format? i.e. if
exchange sends it in 7bit, i'm fine with it. no need for another
translation.

> Perhaps headers do not properly declare content. Do you have an example of
> such a message (inside mutt, just pipe it into "cat - >/tmp/msg.bin", then
> mail msg.bin as application/octet-stream attachment).

in attachment. it's in czech, sorry - only sample i did not deleted

> > 	- fetchmail modifies the "From: " header
> Is it fetchmail or OpenChange or Exchange that does this?

this is what i have when i look out from outlook:
	From: "Matthias Andree" <matthias.andree@your.email>
	To: "mojmir svoboda" <mojmir.svoboda@my.email>, fet...@li...
	Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
	Content-Transfer-Encoding: 7bit

this is what i receive after fetchmailing via mapi:
	From: MatthiasAndree@exchange_server_address.here
	To: 2K Czech <MojmirSvoboda>;, fet...@li...
	Content-Type: text/plain; charset=us-ascii
	Content-Transfer-Encoding: quoted-printable

there is some header manipulation code in mapi_fetch_headers, i'd start
search there.

best regards,
mojmir

Re: [fetchmail-devel] fetchmail and mapi II

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

Am 16.06.2009, 12:27 Uhr, schrieb mojmir svoboda  
<moj...@2k...>:

> first i'd like to note that i am not a mapi specialist.. or anything  
> close to that. i simply have to live with this exchange and not want to  
> use outlook.

No need to justify your goals - your input and observations are useful and  
welcome, even if you cannot provide full solutions to issues that you see.

>> > 3. missing mapi_session* argument
>> > 	affected functions are mapi_init, smtp_address
>> > 	(calls OpenMsgStore, GetGALTable)
>> > 	i had to introduce static global variable for that.
>
> you can find a patch in the attachment. this way it at least compiles  
> and runs.
>
> the things is: if i use s_mapi_session everywhere it stops to work  
> properly in mapi_getauth (MapiLogonProvider creates another session and  
> if the
> s_mapi_session passed as arg, it crashes later in ProcessNetworkProfile)
>
> so the s_mapi_session is shared only between mapi_init and smptp_address  
> for a moment.

I'll save this part and look at it later; perhaps Jelmer can help here.

>> > 4. buffer overflows
>> > 	affected functions get_base64_attachment, octool_get_stream
>> > 	perhaps all these memcpys should be reviewed
>
> i will toy with this few days until i figure what the correct form  
> should be.
>
> as a hotfix i simply allocated lot of memory and removed the loop that  
> did nothing. i assume you do not want that kind of solution (and neither  
> do i.. in long term)

Ah, ok.

>> > 6. \r characters and = spread all around in mail body
>> What is this quoted_printable_encode part doing wrong? Could you provide
>> your solution to (6)? Perhaps we can build a full solution on top of  
>> yours.
>
> errr.. do not overestimate me... i simply removed the code that did not
> suited me ;)
>
> 	for example: what is this supposed to do? 8->7 bit?
> 			if (is_safe_char(ch))
> 				line[line_count++] = ch;
> 			else {
> 				line[line_count++] = '=';
> 				line[line_count++] = hex[(ch >> 4) & 15];
> 				line[line_count++] = hex[ch & 15];
> 			}

This looks like quoted printable encoding to me. hex is likely (i. e. I  
haven't looked at the code) a char array "0123456789ABCDEF" and if it's a  
safe character (no control character), it's emitted directly, otherwise,  
it's encoded as =XX, where XX is the associated ASCII value, expressed as  
a sedecimal number.

> 	if yes i wonder why mutt (set noallow_8bit) displays that incorrectly.

Perhaps headers do not properly declare content. Do you have an example of  
such a message (inside mutt, just pipe it into "cat - >/tmp/msg.bin", then  
mail msg.bin as application/octet-stream attachment).

> 	and then there are these line[line_count++] = '\r';
> 	which are later visible in mutt.

If that's correct depends on the location in the code where you've found  
this.

> 	sincerely, i have no idea what proper solution should look like.
>
> there are more problems:
> 	- fetchmail modifies the "From: " header
> 	- fetchmail seems to drop any list-id and in-reply-to fields (and  
> perhaps
> 	  other fields). this makes mailing lists (and threading) a little bit
> 	  uncomfortable

Is it fetchmail or OpenChange or Exchange that does this?

I recall an internship some 8 years ago where the company also Exchange  
(that was in early 2001), and Emacs+Gnus was rather confused by the output  
(which also included blank lines in places where you didn't expect them,  
and where PINE didn't show them), while PINE worked reasonably well. I  
don't recall how well mutt fared at the time.

HTH
Matthias

-- 
Matthias Andree

Re: [fetchmail-devel] fetchmail and mapi II

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

hello everyone,

first i'd like to note that i am not a mapi specialist.. or anything close to
that. i simply have to live with this exchange and not want to use outlook.


> > 3. missing mapi_session* argument
> > 	affected functions are mapi_init, smtp_address
> > 	(calls OpenMsgStore, GetGALTable)
> > 	i had to introduce static global variable for that.

you can find a patch in the attachment. this way it at least compiles and runs.

the things is: if i use s_mapi_session everywhere it stops to work properly in
mapi_getauth (MapiLogonProvider creates another session and if the
s_mapi_session passed as arg, it crashes later in ProcessNetworkProfile)

so the s_mapi_session is shared only between mapi_init and smptp_address for a
moment.

> > 4. buffer overflows
> > 	affected functions get_base64_attachment, octool_get_stream
> > 	perhaps all these memcpys should be reviewed

i will toy with this few days until i figure what the correct form should be. 

as a hotfix i simply allocated lot of memory and removed the loop that did
nothing. i assume you do not want that kind of solution (and neither do i..
in long term)

> > 6. \r characters and = spread all around in mail body
> What is this quoted_printable_encode part doing wrong? Could you provide
> your solution to (6)? Perhaps we can build a full solution on top of yours.

errr.. do not overestimate me... i simply removed the code that did not
suited me ;)

	for example: what is this supposed to do? 8->7 bit?
			if (is_safe_char(ch))
				line[line_count++] = ch;
			else {  
				line[line_count++] = '=';
				line[line_count++] = hex[(ch >> 4) & 15];
				line[line_count++] = hex[ch & 15];
			}
	if yes i wonder why mutt (set noallow_8bit) displays that incorrectly.

	and then there are these line[line_count++] = '\r';
	which are later visible in mutt.

	sincerely, i have no idea what proper solution should look like. 

there are more problems:
	- fetchmail modifies the "From: " header
	- fetchmail seems to drop any list-id and in-reply-to fields (and perhaps
	  other fields). this makes mailing lists (and threading) a little bit
	  uncomfortable

best regards and thanks for your replies,
mojmir

Re: [fetchmail-devel] mapi support

[Asif I. <va...@gm...>]

On Mon, Jun 15, 2009 at 3:07 AM, Matthias Andree<mat...@gm...> wrote:
> Am 14.06.2009, 14:58 Uhr, schrieb Jelmer Vernooij <je...@op...>:
>
>> Asif Iqbal wrote:
>>>
>>> Is there a chance that fetchmail will add support for mapi?
>>>
>>> I see openmapi and openchange offers some APIs to access mapi servers.
>>>
>>> Our work exchange server only offers access by mapi or https interface.
>>>
>> There is a MAPI branch for fetchmail that was created by a summer of
>> code student a year ago, which adds MAPI support based on OpenChange.
>>
>> Hopefully this branch will be merged back into mainline at some point.
>>
>> I'm happy to help get it to compile against current openchange again, or
>> help testing.
>
> Hi Jelmer,
>
> could you check Mojmir Svoboda's mails of 09/10 June on this list? Some
> issues he has seen may be related to OpenChange updates that entailed API
> changes.
>
> I'm sorry that I neither got around to auditing the code, nor integrating it
> yet.  I plan to release 6.3.10 soonish there is one non-trivial fix pending,
> but I can branch for 6.3.10 to fix up the fallout through release
> candidates, and after that continue towards a new feature branch (6.4.X),
> merging the code if I can get it tested.

Please let me know if I can help with the test. I have access to
exchange server.

>
> Best regards
> Matthias
>
> --
> Matthias Andree
>



-- 
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Re: [fetchmail-devel] mapi support

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

Am 14.06.2009, 14:58 Uhr, schrieb Jelmer Vernooij <je...@op...>:

> Asif Iqbal wrote:
>> Is there a chance that fetchmail will add support for mapi?
>>
>> I see openmapi and openchange offers some APIs to access mapi servers.
>>
>> Our work exchange server only offers access by mapi or https interface.
>>
> There is a MAPI branch for fetchmail that was created by a summer of
> code student a year ago, which adds MAPI support based on OpenChange.
>
> Hopefully this branch will be merged back into mainline at some point.
>
> I'm happy to help get it to compile against current openchange again, or
> help testing.

Hi Jelmer,

could you check Mojmir Svoboda's mails of 09/10 June on this list? Some  
issues he has seen may be related to OpenChange updates that entailed API  
changes.

I'm sorry that I neither got around to auditing the code, nor integrating  
it yet.  I plan to release 6.3.10 soonish there is one non-trivial fix  
pending, but I can branch for 6.3.10 to fix up the fallout through release  
candidates, and after that continue towards a new feature branch (6.4.X),  
merging the code if I can get it tested.

Best regards
Matthias

-- 
Matthias Andree

Re: [fetchmail-devel] mapi support

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

Asif Iqbal wrote:
> Is there a chance that fetchmail will add support for mapi?
>
> I see openmapi and openchange offers some APIs to access mapi servers.
>
> Our work exchange server only offers access by mapi or https interface.
>   
There is a MAPI branch for fetchmail that was created by a summer of
code student a year ago, which adds MAPI support based on OpenChange.

Hopefully this branch will be merged back into mainline at some point.

I'm happy to help get it to compile against current openchange again, or
help testing.

Cheers,

Jelmer

Re: [fetchmail-devel] mapi support

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

Please look at the list archives. This topic has just been discussed.

On 06/14/2009, Asif Iqbal <va...@gm...> wrote:
> Is there a chance that fetchmail will add support for mapi?
>
> I see openmapi and openchange offers some APIs to access mapi servers.
>
> Our work exchange server only offers access by mapi or https interface.
>
> Thanks
>
> --
> Asif Iqbal
> PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> _______________________________________________
> fetchmail-devel mailing list
> fet...@li...
> https://lists.berlios.de/mailman/listinfo/fetchmail-devel
>


-- 
                 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] mapi support

[Asif I. <va...@gm...>]

Is there a chance that fetchmail will add support for mapi?

I see openmapi and openchange offers some APIs to access mapi servers.

Our work exchange server only offers access by mapi or https interface.

Thanks

-- 
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Re: [fetchmail-devel] fetchmail and mapi II

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

Am 10.06.2009, 08:23 Uhr, schrieb mojmir svoboda  
<moj...@2k...>:

> good morning,
>
> i'd like to supply more details for my previous mail:
>
> 3. missing mapi_session* argument
> 	affected functions are mapi_init, smtp_address
> 	(calls OpenMsgStore, GetGALTable)
> 	i had to introduce static global variable for that.
>
> 4. buffer overflows
> 	affected functions get_base64_attachment, octool_get_stream
> 	perhaps all these memcpys should be reviewed
>
> 6. \r characters and = spread all around in mail body
> 	caused by quoted_printable_encode, some weird stuff there.
> 	i fixed it to suite my needs, proper solution needed.

Dear Mojmir,

thanks for the details and taking interest here.

What is this quoted_printable_encode part doing wrong? Could you provide  
your solution to (6)? Perhaps we can build a full solution on top of yours.

Thanks.

Best regards

-- 
Matthias Andree

Re: [fetchmail-devel] fetchmail and mapi

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

Am 09.06.2009, 13:27 Uhr, schrieb mojmir svoboda  
<moj...@2k...>:

> hello dear developpers,
>
> first i'd like to appologize if there is anything wrong with this email.
>
> i was using classic fetchmail | procmail | mutt | ssmtp toolchain until
> the evil begun to spread from the mordor realm. yes, this company
> switched to mordor's exchange and mapi protocol so i found that there
> is BRANCH_MAPI already in the repository.
> i've compiled, installed and configured this branch, but i have few
> notes and questions:

Hi Mojmir,

> 1. when it will be merged to trunk?

As soon as I have the time to look at the code and resolved unsafe  
programming practices and required updates in that code (see your findings  
(3) and (4) below), and tested against an Exchange server (I don't have  
one).

> 2. is there any work in progress? do you accept patches?

I'm not aware that the branch is being worked on. I will accept patches -  
please document them so I can understand what they are trying to do.

> 3. the branch seems not to compile without touching OpenMsg and GetGAL
> because session argument is missing

Has there been a new OpenConnect release since then?

> 4. the branch contains few buffer overflows in openchange-tools.c
> i can supply more info, if you want.

Yes, please do.

> 5. fetchmail -k works successfully, but fetchmail -K does not.
> i have to find more yet.

Please let me know what you find.

> 6. mordor's exchange server seems to append this funny ^M to each line
> in the body. is it the job of fetchmail to remove this, or some procmail
> tool for example (OT: do you know how to code the rule, please?)

That's not only MAPI, but some other protocols are also CRLF terminated.  
It's fetchmail's job to normalize line endings to whatever the destination  
protocol requires. MDA => LF, SMTP => CRLF, for instance.

> 7. (perhaps OT) i wonder how to send back an email via mapi, but i guess
> this is not really a job of fetchmail.

Indeed that's not fetchmail's job, we'll have to check.

Thanks for looking at the code and pointing out there are issues.  
BRANCH_MAPI was a Google Summer of Code project.

Best regards

-- 
Matthias Andree

[fetchmail-devel] fetchmail and mapi II

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

good morning,

i'd like to supply more details for my previous mail:

3. missing mapi_session* argument
	affected functions are mapi_init, smtp_address
	(calls OpenMsgStore, GetGALTable)
	i had to introduce static global variable for that.

4. buffer overflows
	affected functions get_base64_attachment, octool_get_stream
	perhaps all these memcpys should be reviewed

6. \r characters and = spread all around in mail body
	caused by quoted_printable_encode, some weird stuff there.
	i fixed it to suite my needs, proper solution needed.

best regards,
mojmir

[fetchmail-devel] fetchmail and mapi

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

hello dear developpers,

first i'd like to appologize if there is anything wrong with this email.

i was using classic fetchmail | procmail | mutt | ssmtp toolchain until
the evil begun to spread from the mordor realm. yes, this company
switched to mordor's exchange and mapi protocol so i found that there
is BRANCH_MAPI already in the repository.
i've compiled, installed and configured this branch, but i have few
notes and questions:

1. when it will be merged to trunk?

2. is there any work in progress? do you accept patches?

3. the branch seems not to compile without touching OpenMsg and GetGAL
because session argument is missing

4. the branch contains few buffer overflows in openchange-tools.c
i can supply more info, if you want.

5. fetchmail -k works successfully, but fetchmail -K does not.
i have to find more yet.

6. mordor's exchange server seems to append this funny ^M to each line
in the body. is it the job of fetchmail to remove this, or some procmail
tool for example (OT: do you know how to code the rule, please?)

7. (perhaps OT) i wonder how to send back an email via mapi, but i guess
this is not really a job of fetchmail.

many thanks for your attention,
mojmir

[fetchmail-devel] New Russian PO file for 'fetchmail' (version 6.3.10-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 Russian team of translators.  The file is available at:

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

(This file, 'fetchmail-6.3.10-pre1.ru.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.8: "Invalid SSL protocol..." Error

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

Am 03.06.2009, 17:00 Uhr, schrieb Vitezslav Crhonek <vcr...@re...>:

> it seems that Stefano was right - the problem still exists in some  
> circumstances. See
> https://bugzilla.redhat.com/show_bug.cgi?id=503881
>
> Best regards,
> Vitezslav Crhonek

Vitezslav,

you've written "reproduced" in Bugzilla; so if _you_ have a configuration  
that shows this problem, please send it so I can start fixing, and perhaps  
later look if the configuration of the original submitter is also fixed.

I think there is potential in the code to trigger such issues, but I don't  
yet know how (what the control flow is that leads to the problem).  Before  
I fix this deep down the code, I want to make sure that we're free of  
other bugs in the SSL/TLS logic in the socket.c SSLOpen() callers.

Thanks in advance.

Best regards

-- 
Matthias Andree

Re: [fetchmail-devel] Fetchmail 6.3.8: "Invalid SSL protocol..." Error

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

Am 03.06.2009, 17:00 Uhr, schrieb Vitezslav Crhonek <vcr...@re...>:

> Hi,
>
> it seems that Stefano was right - the problem still exists in some  
> circumstances. See
> https://bugzilla.redhat.com/show_bug.cgi?id=503881
>
> Best regards,
> Vitezslav Crhonek

Hi Vitezslav,

could you please request the original fetchmailrc (with only passwords and  
login masked but everything else unchanged) from the original reporter? I  
need that file to reproduce the problem on my end.

Thanks in advance.

Best regards
Matthias Andree

-- 
Matthias Andree

Re: [fetchmail-devel] Fetchmail 6.3.8: "Invalid SSL protocol..." Error

[Vitezslav C. <vcr...@re...>]

Hi,

it seems that Stefano was right - the problem still exists in some circumstances. See
https://bugzilla.redhat.com/show_bug.cgi?id=503881

Best regards,
Vitezslav Crhonek


----- Original Message -----
From: "Stefano" <fet...@po...>
To: "Matthias Andree" <mat...@gm...>
Cc: fet...@li...
Sent: Sunday, March 16, 2008 5:22:05 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: [fetchmail-devel] Fetchmail 6.3.8: "Invalid SSL protocol..."	Error

Evidently, I should have looked more closely at the latest development  
code in the repository.  The particular problem I was having does  
indeed appear to have been fixed in BRANCH_6-3 (checked it out and  
built a few hours ago).

However, is there not a chance that a similar problem will return in  
the event that the "defeat opportunistic STLS" block *is* executed?   
It seems that the only thing that was done is to avoid going through  
that block in the particular case of a required re-poll when an  
opportunistic STLS negotiation was not attempted.  Without changing  
the sslproto = "" aspect of that block, or the handling in socket.c,  
does the potential for the problem to return not remain?

Quoting Matthias Andree <mat...@gm...>:

> On Sat, 15 Mar 2008, Stefano wrote:
>
>> I recently installed Fetchmail (6.3.8) to collect my mail from various
>> accounts, so that they could be automatically filtered and sorted. Since
>> installation, I had been getting the following error whenever it polled
>> my ISP's server (POP3):
>>
>> Invalid SSL protocol '' specified, using default (SSLv23).
>>
>> This does not happen when accessing other IMAP servers, but they don't
>> support IMAP.  Given that I had added a cron job to check the accounts
>> periodically, I kept receiving messages from the cron daemon with these
>> errors; rather irritating.  Thus began my quest to track down and
>> silence the error.
>
> Well, try the attached patch and see if it helps, it's actually simpler.
>
> If the NEWS or TODO.txt parts of the patch fail, nevermind.
>
>> I had read about this problem while trying to solve it, but it didn't
>> seem to have been fixed in the latest development code, so I took a stab
>> at it.
>
> It should be fixed in the SVN repository though,
>
> http://mknod.org/svn/fetchmail/branches/BRANCH_6-3/
>
> (That's where my patch comes from.)
>
> If not, we'll check again how to fix this.
>
> Thanks a lot for your report and patch!
>
> --
> Matthias Andree
>

_______________________________________________
fetchmail-devel mailing list
fet...@li...
https://lists.berlios.de/mailman/listinfo/fetchmail-devel

[fetchmail-devel] New Polish PO file for 'fetchmail' (version 6.3.10-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 Polish team of translators.  The file is available at:

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

(This file, 'fetchmail-6.3.10-pre1.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 Spanish PO file for 'fetchmail' (version 6.3.10-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 Spanish team of translators.  The file is available at:

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

(This file, 'fetchmail-6.3.10-pre1.es.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 Chinese (simplified) PO file for 'fetchmail' (version 6.3.10-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 Chinese (simplified) team of translators.  The file is available at:

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

(This file, 'fetchmail-6.3.10-pre1.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 Indonesian PO file for 'fetchmail' (version 6.3.10-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 Indonesian team of translators.  The file is available at:

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

(This file, 'fetchmail-6.3.10-pre1.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 Japanese PO file for 'fetchmail' (version 6.3.10-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 Japanese team of translators.  The file is available at:

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

(This file, 'fetchmail-6.3.10-pre1.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 Czech PO file for 'fetchmail' (version 6.3.10-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.10-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 Czech PO file for 'fetchmail' (version 6.3.10-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.10-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...>

Re: [fetchmail-devel] [fetchmail-users] fetchmail 6.3.10-beta1 test version

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

Am 26.05.2009, 00:30 Uhr, schrieb Matthias Andree <mat...@gm...>:

> I have uploaded a fetchmail 6.3.10 beta version - "beta" means that some
> of the bug fixes have been nontrivial, and testing is required. See the
> log below for bugs supposed to be fixed.

Details on required testing in 6.3.10-beta1:

- does fetchmail leave undeliverable messages on the server by default?

- does NTLM authentication with M$ Exchange still work? (It works with  
Cyrus IMAP.)

- does fetchmail now properly continue on Exchange messages that have no  
body?
   (Some Exchange versions respond with "NIL" rather than "0 bytes" -  
fetchmail up to 6.3.9 did not handle that and hung.)

- does fetchmail-generated bounce mail still look right?

Please also look at the README.SSL and README.SSL-SERVER documents and  
pinpoint sections you find hard to read, hard to understand, or if  
information is missing; same goes for the manual page.

If you can offer a test account free of charge, i. e. an account where I  
can send a short email and retrieve it via POP3, IMAP, or other supported  
protocols, I'd be happy to take such offers.

Thanks a lot!

Best regards

-- 
Matthias Andree