fetchmail-devel — Development related discussion

[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: 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: 2010-Apr-09 09:51
By: m-a

Comment:
Benno,

can I _please_ get a verbose trace showing the message loss? Thank you.
-------------------------------------------------------

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 #16000] fetchmail should support multiple sslfingerprints

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

Bug #16000, was updated on 2009-Jul-16 02:40
Here is a current snapshot of the bug.

Project: fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: jw9
Assigned to : none
Summary: fetchmail should support multiple sslfingerprints

Details: Some mail servers, such as pop3.live.com, have multiple hosts available at a single IP address (currently pop3.live.com appears to have two hosts behind that one IP address).

Other mail servers, such as imap.gmail.com, resolve to rotating IP addresses.

It should be possible to specify multiple 'sslfingerprint' entries so that any one of those fingerprints can match.


Follow-Ups:

Date: 2010-Apr-09 09:49
By: m-a

Comment:
I have reconsidered the issue and raised the bug priority.

It would seem that such a security feature is warranted even in a stable release to counter MITM attacks that exchange certificates on the flight.
-------------------------------------------------------

Date: 2009-Aug-19 11:13
By: m-a

Comment:
reopening after grarpamp's comments.

On the suggestion, based on the rationale below, I might indeed rather correct the documentation and indeed support certificate fingerprint lists. I do however not subscribe to the assertion that the fingerprint were necessary to detect MITM attacks - the certificates should be sufficient as long as you're happy with the signing CA's verification policies (including the hash used).

I currently second the view that verifying both the MD5 and SHA1 of a certificate has been considered reasonably safe recently, i. e. I'm not aware of efficient attacks that collide both MD5 and SHA1 at the same time.

I wonder if the hash grouping can be configured in a simpler way, for instance --sslfingerprint {MD5}DE:AD:BE:...:EF&{SHA1}F0:0D:04:13:...:37 or similar. I'll need to think about this a bit more when it comes to the real implementation. It may be awkward to edit on your netbook screen or smartphone, but it's likely simpler to implement.

Given this is more a feature request than a real bug, it will probably not make a 6.3.X release though.
-------------------------------------------------------

Date: 2009-Aug-11 23:55
By: grarpamp

Comment:
Adding content for those who use this interface... 

Hi :) Folks appear to be misunderstanding things
about the underlying crypto and why fingerprints are a necessary
safety check.

If one simply relies on checking the cert chain and blindly trusts
that model, as most of the world is conditioned to believe it is
sound, you are open to attack. Namely, of the sort in the posted
url, it is a good read, as are the referenced prior art. Both MD5
and SHA1 are theory broken and MD5 demonstrably so, as noted in the
literatre. So the hash part is of concern, at least in this case.

A CA takes a MD5 over certain fields in the cert and signs that MD5
digest, not the entire cert contents. CA's previously used MD5 and
failed to change their cert practices to SHA1 until a real world
break, oops. Anyways... So I don't have to swipe their private key.
All I have to do to forge a server cert is copy the signature from
any candidate real cert into my cert and manufacture the rest of
my cert contents so that they: a) work, b) make the fields have the
same digest as the real one. Which, as we all know by now is possible,
given time or new art, due to the whole hash collision thing.

However... if I copy a known good cert via trusted channels, and
take both the MD5 and SHA1 fingerprints of the DER form of that
cert, it's much closer to cryptographically impossible to manufacture
a cert that would match evarything. I could just as easily make
formal contact with the cert holder and get the prints that way or
receive them as part of a high security programme. Banks do this.

So there are two different fingerprints covering different areas.

Checking fingerprints over the entire DER cert will foil this attack
because it detects the contents that I manipulated to match the
field digest that was later signed. That is why openssl, browsers,
ssh, etc provide fingerprint calculating and verification functions...
totally separate from signature calc/verif capabilities.

So two types of checks should always be performed for maximum
security:

 A) cert chain trust = sig(hash(contents)) -> pki
  This is done with openssl verify -verbose
  aka: sslcertck
 B) DER fingerprint = hash(sig(hash(contents))
  This is done with openssl x509 -in <PEMcert> -noout -fingerprint -<sha1|md5>
   or
  openssl x509 -in <PEMcert> -outform DER | <sha1|md5>
  aka: sslfingerprint... with the enhancements in the prior note

Enhancing fetchmail to doubly check B with both MD5 and SHa1 shouldn't
be much extra coding or user effort. As an aside, it's fairly common
to find places using/publishing both hashes for various purposes.

Removing the check in B places all the beans on the hash function
in A, which is not good. Private keys are not even involved in this.
Defense in depth will save your butt :)

Give the user tools, let them decide how many they wish to deploy
and manage. I would adapt the docs to say that one should use both
A and B, or neither, with some short reasons why. And continue to
provide example openssl usage as is there now, to allow them to
accomplish it.

Note1: Not checking the fingerprints on self-signed certs... such
as are commonly found in internal corporate nets, edu's, org's, and
the many end user, developer, hacker and other low budget/tier
sites... is asking for trouble. Not publishing your prints, signed
by OpenPGP, is bad too.

Note2: The random serial fix just helps eliminate easier forms of
the hash collision attack, see the paper. It doesn't necessarily
prevent other forms or completely new math attacks, and definitely
doesn't prevent brute force.

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

I'm out of time at the moment to
help out with correcting what is already in here, perhaps later.

Thanks again for keeping up with all the maintenance to fetchmail :)
-------------------------------------------------------

Date: 2009-Aug-11 23:50
By: none

Comment:
Adding content for those who use this interface...

Hi all :)

Fetchmail needs the ability to specify multiple 'sslfingerprint'
options and digests per 'poll' stanza.
  
I noticed this when connecting to gmail. I think it's a load sharing
thing providers use. Google also has their own intermediate CA now
so more cert deployments could be expected.
  
At the moment, if you specify multiple sslfingerprint rc lines or
command line options, only the last one specified is checked. Any
prior sslfingerprint options are silently ignored. And the only
digest available is md5.
  
This is obviously frustrating users mail collection attempts :(
  
  
To reproduce the problem, run this and examine the certs and hashes.
The gmail certs happen to verify back to the root CA's. The
44a8...f1a9 cert occurs more frequently, the 9273...9f33 cert is
rarer. I've attached them both and the CA's involved.
  
If you are not seeing multiple certs, you may need to 'travel' and
debug with different source ip addresses... such as provided with
a worldwide proxy network like Tor.
  
i=10 ; while : ; do
 LD_PRELOAD=/tmp/tor/libtsocks.so.1 TSOCKS_CONF_FILE=/tmp/tor/tsocks.conf \
  openssl s_client -connect pop.gmail.com:pop3s < /dev/null > tcert$i 2>&1
 echo -n "$i: "
 openssl x509 -noout -fingerprint -md5 -in tcert$i
 i=`expr $i + 1`
done
  
  
Also related... from the BRANCH_6-3 NEWS file:
  
* --sslfingerprint may be removed from a future fetchmail version,
 because it's just too easily abused to create a false sense of
 security.
  
PLEASE don't remove this feature. I like it a lot and use it
everywhere possible, with --ssl and --sslcertck at the same time
as well, from trusted sources beforehand of course. Knowing when
the cert changes out from under you is very useful, even if only
for debugging or system verification. Especially if you connect
from untrusted locations or paths. Or you want to know about and
resolve them. It's also handy if the machine a user is connecting
from has a poor, untrusted or nonexistent collection of CA certs.
In that case, just the digest can be imported and used. Note that
openssl does not ship with a CA cert collection... admins usually
have to get it from mozilla... if they value PKI enough to think
of and bother with it.

There are blurbs in the man page that even talk about self-signed
certs being accepted with 'sslcertck'.


Overall, it would be good to see this feature enhanced to do both
md5 and sha1 to make cert collision attacks much more improbable
going forward... at least until the NIST 'SHA-3' hash competition
is done and that trickles down to the CA's and apps years from now.
Usage in the case of a single cert, where both must match, might
be like...

poll
 sslfingerprint-md5 <fp_md5>
 sslfingerprint-sha1 <fp_sha1>

In the case where multiple certs may be presented, group the hashes
as a set. Both hashes in the set must match. First check set cert1,
then set cert2, then set cert[n] until one set, or none, match the
presented cert...

poll
 sslfingerprint-cert1-md5 <fp_md5>
 sslfingerprint-cert1-sha1 <fp_sha1>
 sslfingerprint-cert2-md5 <fp_md5>
 sslfingerprint-cert2-sha1 <fp_sha1>
 sslfingerprint-cert[n]-md5 <fp_md5>
 sslfingerprint-cert[n]-sha1 <fp_sha1>

The '--' command line version of this should also do the right
thing.

Fetchmail should also print both the md5 and sha1 fingerprints from
the received certificate in the debug output.

Note that openssl supports mdc2, md2, md5, sha1. I understand that
some CA's also used, or may still use, the non-sha1 digests. Though
I guess sha1 is the only one used by sane CA's for new certs these
days. I don't know how many old ones are still in use on hosts. md5
and sha1 are enough until SHA-3.

And since the past always seems to apply to some future scenario
with new twists, this is surely not the last of the breed to be
proven out: http://www.win.tue.nl/hashclash/rogue-ca/

Extra checks are always good thing to have available.
Openssl probably has simple library routines to do this.

Thanks guys, and for fetchmail too, been using it for years :)
-------------------------------------------------------

Date: 2009-Jul-16 20:20
By: m-a

Comment:
Compatibility. Basically 6.3.X should be as compatible with 6.2.0 as reasonably possible - and it turned out that 6.3.X has lived for quite a while now... Compatibility was needed at the time to pave the upgrade path for 6.2.X users, as 6.3.0 had around one hundred bug fixes over 6.2.5 - and those were more important than cleanups.
-------------------------------------------------------

Date: 2009-Jul-16 17:44
By: jw9

Comment:
Good.

You should remove sslfingerprint asap.

Cannot understand why the feature was implemented in the first place.  And why such a broken "feature" has endured for so long.

Have a nice day.

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

Date: 2009-Jul-16 15:19
By: m-a

Comment:
[Now the bug tracker is messing things up, my comment appeared twice in spite of being submitted once around 14:35, not again at 15:03. Sorry for that, but it has happened outside my control.]

I don't doubt your technical and intellectual skills to download the server's certificate or its fingerprint. BUT then your security hinges on the useless assumption that your connection is not under attack in the very moment that you're downloading the cert/fingerprint. You can't know if you're under attack unless you can verify the FP through a secure channel: You're using the same channel you'd later use for the actual mail-fetching connection; so you'd happily download the attacker's certificate or fingerprint.

Fetching the fingerprint through a DIFFERENT or at least a known-secure channel is crucial here.

I will not abolish the option for 6.3.X versions for compatibility reasons. If I'll drop it later is left for later decision, as the fingerprint is the easier alternative compared to downloading the *server* certificate and stuffing it into <prefix>/ssl/certs/. The canonical way is still to install the root-signing certificate though.

I don't see much use in listing hundreds of ssl fingerprints and keeping that list up to date when instead you can just save the certificate of the signing CA. It's less of a hassle. And if you can't trust, for instance, CyberTrust, then don't install their certificate, but Microsoft's certificate instead - providing you have a way of verifying that...

I'll see to marking the sslfingerprint feature candidate for removal for 6.4.X or newer fetchmail releases.
-------------------------------------------------------

Date: 2009-Jul-16 15:03
By: m-a

Comment:
Two things:

1a. sslfingerprint is unnecessary in "--sslcertck --sslproto tls1" and in "--sslcertck --sslproto ssl3 --ssl" configurations, and shouldn't be used. It doesn't add security unless your ISP provides you with the finger prints through a separate channel (such as your walking up to the site and fetching a sheet with finger prints).

The assumption is that the MITM (=attacker) cannot forge the signature of the certification authorities you trust. He may forge the server's certificate, but he'll hardly be able to forge the root signing certificate from Equifax, Verisign, or whoever. sslcertck is sufficient unless you follow stupid guides that suggest capturing and saving the server certificate (while that works to shut up complaints about certificates, it doesn't add protection against MITM attacks: you might already download the counterfeit certificate that you save as trusted, if you're already under attack at the time).

1b. sslfingerprint, as you observed, isn't useful with certain load balancing setups, when servers have individual certificates that are signed by a common CA.

2. for complaints about the newest-first ordering of the comments, please file a support request against BerliOS itself, not against individual projects.
-------------------------------------------------------

Date: 2009-Jul-16 15:02
By: jw9

Comment:
I can determine the proper fingerprint from any other server on any other network that I have access to.  I don't have to ask any "ISP" to provide fingerprints through another channel because I am quite able to do that myself.

So, as you state, it does add extra security.  Especially in today's world where most people have access to more than one "ISP" or network (eg your workplace if you have one, and most people do!).

In which case you should allow a set of sslfingerprints to be specified.

Otherwise, to be consistent with your argument (that sslfingerprint is unnecessary), you should completely remove the sslfingerprint option.

Fix it or lose it.

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

Date: 2009-Jul-16 14:35
By: m-a

Comment:
Two things:

1a. sslfingerprint is unnecessary in "--sslcertck --sslproto tls1" and in "--sslcertck --sslproto ssl3 --ssl" configurations, and shouldn't be used. It doesn't add security unless your ISP provides you with the finger prints through a separate channel (such as your walking up to the site and fetching a sheet with finger prints).

The assumption is that the MITM (=attacker) cannot forge the signature of the certification authorities you trust. He may forge the server's certificate, but he'll hardly be able to forge the root signing certificate from Equifax, Verisign, or whoever. sslcertck is sufficient unless you follow stupid guides that suggest capturing and saving the server certificate (while that works to shut up complaints about certificates, it doesn't add protection against MITM attacks: you might already download the counterfeit certificate that you save as trusted, if you're already under attack at the time).

1b. sslfingerprint, as you observed, isn't useful with certain load balancing setups, when servers have individual certificates that are signed by a common CA.

2. for complaints about the newest-first ordering of the comments, please file a support request against BerliOS itself, not against individual projects.
-------------------------------------------------------

Date: 2009-Jul-16 13:09
By: jw9

Comment:
It would appear that additional comments appear in a push-down stack order.  This makes it very hard to follow the natural order of things.  This is very strange.

Here in the western world we are used to reading left-to-right and top-to-bottom.  We certainly don't expect to have to read from bottom-to-top.

I suppose I can turn my monitor upside down and then they might follow in a proper order.  But wait, that would make the characters appear upside-down!

In any case, if one is to be able to check the sslfingerprint of a server to protect against man-in-the-middle attacks, and if the fingerprint does actually change randomly (and not because of a man-in-the-middle attack), then we need to be able to specify a set of fingerprints and only require that at least one of them matches.

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

Date: 2009-Jul-16 13:03
By: jw9

Comment:
Why do comments appear in such a strange place (after my original submission)?  Shouldn't additional comments follow in a logical order after other people's followup comments?  Very strange!

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

Date: 2009-Jul-16 13:00
By: jw9

Comment:
II think you misunderstand.  The sslfingerprint is used to verify the identity of the server and to protect against man-in-the-middle attacks.  The configuration also has proper certificate and "ssslcertck" and "sslcertpath" settings.

To protect again man-in-the-middle attacks one needs to be able to ensure that the fingerprint of the server hasn't changed.

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

Date: 2009-Jul-16 12:33
By: m-a

Comment:
I don't think fetchmail should do that.

sslfingerprints are just a convenience shortcut, and closely resemble stuffing the server's certificate into the directory of trusted certification authority certificates, usually /usr/ssl/certs, /etc/ssl/certs (and running c_rehash afterwards), or similar.

The canonical way is to install the GTE CyberTrust Global Root (for Microsoft/live.com) or the Equifax Secure Certificate Authority (for Google Mail) and use certificate-based authentication.

See also:
http://gagravarr.org/writing/openssl-certs/others.shtml
-------------------------------------------------------

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

[fetchmail-devel] [Bug #17067] Typo in man page

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

Bug #17067, was updated on 2010-Apr-08 22:06
Here is a current snapshot of the bug.

Project: fetchmail
Category: None
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: bob5972
Assigned to : m-a
Summary: Typo in man page

Details: I noticed that the man page for fetchmail says "spambounce" where it should say "softbounce."  Here's a git patch.


>From 6c2a077398458ec8585aac5398f545e30b9573d4 Mon Sep 17 00:00:00 2001
From: Michael Banack <bo...@gm...>
Date: Thu, 8 Apr 2010 12:57:12 -0700
Subject: [PATCH] Fixed typo in the man page

---
 fetchmail.man |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fetchmail.man b/fetchmail.man
index 9b1b41f..a2cc038 100644
--- a/fetchmail.man
+++ b/fetchmail.man
@@ -1666,7 +1666,7 @@ set no softbounce	\&	\&	T{
 Delete permanently undeliverable mail. It is recommended to use this
 option if the configuration has been thoroughly tested.
 T}
-set    spambounce	\&	\&	T{
+set    softbounce	\&	\&	T{
 Keep permanently undeliverable mail as though a temporary error had
 occurred (default).
 T}
-- 
1.7.0.4



Follow-Ups:

Date: 2010-Apr-09 09:46
By: m-a

Comment:
Good catch, and thanks for the patch! I have modified the changelog entry and added a NEWS entry in a separate commit.  The patch is now available in Git's master branch, see http://gitorious.org/fetchmail/fetchmail/commits/master
-------------------------------------------------------

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

[fetchmail-devel] [Bug #17067] Typo in man page

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

Bug #17067, was updated on 2010-Apr-08 13:06
Here is a current snapshot of the bug.

Project: fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: bob5972
Assigned to : none
Summary: Typo in man page

Details: I noticed that the man page for fetchmail says "spambounce" where it should say "softbounce."  Here's a git patch.


>From 6c2a077398458ec8585aac5398f545e30b9573d4 Mon Sep 17 00:00:00 2001
From: Michael Banack <bo...@gm...>
Date: Thu, 8 Apr 2010 12:57:12 -0700
Subject: [PATCH] Fixed typo in the man page

---
 fetchmail.man |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fetchmail.man b/fetchmail.man
index 9b1b41f..a2cc038 100644
--- a/fetchmail.man
+++ b/fetchmail.man
@@ -1666,7 +1666,7 @@ set no softbounce	\&	\&	T{
 Delete permanently undeliverable mail. It is recommended to use this
 option if the configuration has been thoroughly tested.
 T}
-set    spambounce	\&	\&	T{
+set    softbounce	\&	\&	T{
 Keep permanently undeliverable mail as though a temporary error had
 occurred (default).
 T}
-- 
1.7.0.4



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

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

[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

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

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.16)

[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

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

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 French PO file for 'fetchmail' (version 6.3.16)

[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 French team of translators.  The file is available at:

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

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

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

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

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

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

[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

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

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.16.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.16.tar.bz2

We can arrange things so that translated PO files are automatically e-mailed
to you when they arrive.  Ask at the address below if you want this.

Thank you for all your work,

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

[fetchmail-devel] fetchmail 6.3.16 bugfix release

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

Greetings,

I am announcing the release of fetchmail 6.3.16.  This new stable
version of fetchmail fixes --interface support broken in 6.3.15 and
improves SSL compatibility with some site; details below.

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

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

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

fetchmail-6.3.16 (released 2010-04-06, 25574 LoC):

# BUG FIX
* Fix --interface option, broken in 6.3.15. Reported by Vladmimir Stavrinov.
  Fixes Debian Bug #576717.

# CHANGE
* Call OpenSSL_add_all_algorithms(). This is needed to support non-mandatory
  algorithms in certificates. Sjoerd Simons, to fix Debian Bug #576430.
  OpenSSL 0.9.8* does not load - for instance - the SHA256 digest by default.
  Reported as OpenSSL RT#2224.


By popular demand, diffs from the previous release have been omitted.

-- 
Matthias Andree

Re: [fetchmail-devel] CR missing in messages of 6.3.15-beta2 ?

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

Am 29.03.2010, 09:25 Uhr, schrieb Frédéric Marchal:

> On Sunday 28 March 2010, Matthias Andree wrote:
>> (sorry for breaking the threading and the late reply, this message was  
>> lost
>> in transit of eaten by my spam filter; I'm replying from the web  
>> archives
>> where I lack message-id headers)
>>
>> Frédéric Marchal wrote:
>> > Hello,
>> >
>> > I just noticed that the message printed in rfc822.c at line 76:
>> >
>> >     if (outlevel >= O_DEBUG)
>> > 	report_build(stdout, GT_("About to rewrite %s"), buf);
>> >
>> > doesn't end with a \n. The next message written at line 212 is  
>> therefore
>> > concatenated with this one.
>>
>> That's bad and I think it's a bug. I think I'll fix it after the 6.3.15
>> release so as not to break the translations of this message.
>
> It only occurs when -vv is in the command line so it is really a trivial
> issue.

Fixed for me in  
<http://gitorious.org/fetchmail/fetchmail/commit/f333f5cf33a6acdaeb39f7c707ec82012063770f>

>> > The same may be true for the message printed in driver.c starting at  
>> line
>> > 619:
>> >
>> > 		report_build(stdout, GT_("reading message %s@%s:%d of %d"),
>> > 			     ctl->remotename, ctl->server.truename,
>> > 			     num, count);
>> >
>> > 		if (len > 0)
>> > 		    report_build(stdout, wholesize ? GT_(" (%d octets)")
>> >
>> > 				 : GT_(" (%d header octets)"), len);
>> >
>> > In my log, it is concatenated with the above mentioned message.
>>
>> Can you show a sample for that?  I think the LF is deliberately missing
>> here, because we want to add the dots ticker, but OTOH if that's not  
>> going
>> to be displayed, we do need the LF.
>
> The lines are going to be wrapped by the mailer so I add one additional  
> blank
> line after each LF of the original log.
>
> Mar 29 07:11:53 mail fetchmail[3045]: lecture du message ww...@mm...:37  
> parmi
> 396 (20695 octets)#012Sur le point de réécrire Return-path:
> <amb...@xr...>#015#012#012La version réécrite est Return-path:
> <amb...@xr...>#015#012
>
> Mar 29 07:11:53 mail fetchmail[3045]: Sur le point de réécrire From:  
> Barillo
> Schoreplum <amb...@xr...>#015#012#012La version réécrite est From:
> Barillo Schoreplum <amb...@xr...>#015#012
>
> Mar 29 07:11:53 mail fetchmail[3045]: Sur le point de réécrire To:  
> Bansmer
> Selis <lau...@wo...>#015#012#012La version réécrite est  
> To:
> Bansmer Selis <lau...@wo...>#015#012
>
> Mar 29 07:11:53 mail fetchmail[3045]: passage au travers de
> lau...@wo... et coïncidence avec wowcompany.com
>
> Mar 29 07:11:53 mail fetchmail[3045]: réexpédition vers localhost
>
> Mar 29 07:11:53 mail fetchmail[3045]: SMTP> MAIL  
> FROM:<amb...@xr...>
> SIZE=20695
>
> Mar 29 07:11:53 mail fetchmail[3045]: SMTP< 250 2.1.0 Ok
>
> I see no dot tickers.

That's OK. They're printed on console logs only, unless you force them  
with --showdots.

I agree that there's still some intermixing of different topics in the  
logging, particularly of progress and debug logging - I know it's ugly,  
but there are bigger issues in the code, so I don't want to spend too much  
time here just now.

-- 
Matthias Andree

Re: [fetchmail-devel] CR missing in messages of 6.3.15-beta2 ?

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

On Sunday 28 March 2010, Matthias Andree wrote:
> (sorry for breaking the threading and the late reply, this message was lost
> in transit of eaten by my spam filter; I'm replying from the web archives
> where I lack message-id headers)
>
> Frédéric Marchal wrote:
> > Hello,
> >
> > I just noticed that the message printed in rfc822.c at line 76:
> >
> >     if (outlevel >= O_DEBUG)
> > 	report_build(stdout, GT_("About to rewrite %s"), buf);
> >
> > doesn't end with a \n. The next message written at line 212 is therefore
> > concatenated with this one.
>
> That's bad and I think it's a bug. I think I'll fix it after the 6.3.15
> release so as not to break the translations of this message.

It only occurs when -vv is in the command line so it is really a trivial 
issue.

> > The same may be true for the message printed in driver.c starting at line
> > 619:
> >
> > 		report_build(stdout, GT_("reading message %s@%s:%d of %d"),
> > 			     ctl->remotename, ctl->server.truename,
> > 			     num, count);
> >
> > 		if (len > 0)
> > 		    report_build(stdout, wholesize ? GT_(" (%d octets)")
> >
> > 				 : GT_(" (%d header octets)"), len);
> >
> > In my log, it is concatenated with the above mentioned message.
>
> Can you show a sample for that?  I think the LF is deliberately missing
> here, because we want to add the dots ticker, but OTOH if that's not going
> to be displayed, we do need the LF.

The lines are going to be wrapped by the mailer so I add one additional blank 
line after each LF of the original log.

Mar 29 07:11:53 mail fetchmail[3045]: lecture du message ww...@mm...:37 parmi 
396 (20695 octets)#012Sur le point de réécrire Return-path: 
<amb...@xr...>#015#012#012La version réécrite est Return-path: 
<amb...@xr...>#015#012

Mar 29 07:11:53 mail fetchmail[3045]: Sur le point de réécrire From: Barillo 
Schoreplum <amb...@xr...>#015#012#012La version réécrite est From: 
Barillo Schoreplum <amb...@xr...>#015#012

Mar 29 07:11:53 mail fetchmail[3045]: Sur le point de réécrire To: Bansmer 
Selis <lau...@wo...>#015#012#012La version réécrite est To: 
Bansmer Selis <lau...@wo...>#015#012

Mar 29 07:11:53 mail fetchmail[3045]: passage au travers de 
lau...@wo... et coïncidence avec wowcompany.com

Mar 29 07:11:53 mail fetchmail[3045]: réexpédition vers localhost

Mar 29 07:11:53 mail fetchmail[3045]: SMTP> MAIL FROM:<amb...@xr...> 
SIZE=20695

Mar 29 07:11:53 mail fetchmail[3045]: SMTP< 250 2.1.0 Ok

I see no dot tickers.

Frederic

[fetchmail-devel] fetchmail 6.3.15 feature release

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

Greetings,

I am announcing the release of fetchmail 6.3.15.  This new stable
version of fetchmail adds the long-desired feature to download messages
with malformed headers (note this is disabled by default, 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 since the previous release.  Unless
otherwise noted, changes to this release were made by Matthias Andree:

fetchmail-6.3.15 (released 2010-03-28, 25572 LoC):

# FEATURE
* Fetchmail now supports a bad-header command line or rcfile option that takes
  exactly one argument, accept or reject (default).  This specifies how messages
  with bad headers retrieved from the current server are to be treated.

# BUG FIXES
* In the rcfile, recognize "local" as abbreviation for "localdomains", as
  documented. The short form has not ever worked since this feature was added in
  January 1997. Reported by Frédéric Marchal.
* Do not close stdout when using mda and "bsmtp -" at the same time.
* Log operating system errors when BSMTP writes fail.
* Fix verbose mode progress formatting regression from 6.3.10; SMTP trace lines
  were no longer on a line of their own. Reported by Melchior Franz.
* Check seteuid() return value and abort running MDA if switch fails.
* Set global flags in a consistent manner. Make --nosoftbounce and
  --nobounce work from command line (these used to work in rcfiles).
  Reported and fix confirmed working by N.J. Mann. (Sunil Shetye)
* Properly import h_errno declarations, even on systems where h_errno isn't a
  macro. (Adds ./configure check, fixes Cygwin dllimport warnings.)

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

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

# TRANSLATION UPDATES, by language name
* [zh_CN] Chinese (Simplified), by Ji Zheng-Yu
* [cs]    Czech, by Petr Pisar
* [nl]    Dutch, by Erwin Poeze
* [fr]    French, by Frédéric Marchal
* [de]    German
* [id]    Indonesian, by Andhika Padmawan
* [it]    Italian, by Vincenzo Campanella
* [ja]    Japanese, by Takeshi Hamasaki
* [pl]    Polish, by Jakub Bogusz
* [vi]    Vietnamese, by Clytie Siddall

By popular demand, diffs from the previous release have been omitted.

-- 
Matthias Andree

Re: [fetchmail-devel] CR missing in messages of 6.3.15-beta2 ?

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

(sorry for breaking the threading and the late reply, this message was lost in
transit of eaten by my spam filter; I'm replying from the web archives where I
lack message-id headers)

Frédéric Marchal wrote:

> Hello,
> 
> I just noticed that the message printed in rfc822.c at line 76:
> 
>     if (outlevel >= O_DEBUG)
> 	report_build(stdout, GT_("About to rewrite %s"), buf);
> 
> doesn't end with a \n. The next message written at line 212 is therefore 
> concatenated with this one.

That's bad and I think it's a bug. I think I'll fix it after the 6.3.15 release
so as not to break the translations of this message.

> The same may be true for the message printed in driver.c starting at line 619:
> 
> 		report_build(stdout, GT_("reading message %s@%s:%d of %d"),
> 			     ctl->remotename, ctl->server.truename,
> 			     num, count);
> 
> 		if (len > 0)
> 		    report_build(stdout, wholesize ? GT_(" (%d octets)")
> 				 : GT_(" (%d header octets)"), len);
> 
> In my log, it is concatenated with the above mentioned message.

Can you show a sample for that?  I think the LF is deliberately missing here,
because we want to add the dots ticker, but OTOH if that's not going to be
displayed, we do need the LF.

Thanks for your report.

-- 
Matthias Andree

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

[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.15.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 Dutch PO file for 'fetchmail' (version 6.3.15)

[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 Dutch team of translators.  The file is available at:

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

(This file, 'fetchmail-6.3.15.nl.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.15)

[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.15.id.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

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

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

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

(This file, 'fetchmail-6.3.15.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 French PO file for 'fetchmail' (version 6.3.15)

[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 French team of translators.  The file is available at:

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

(This file, 'fetchmail-6.3.15.fr.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.15)

[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.15.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 Italian PO file for 'fetchmail' (version 6.3.15)

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

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

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

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

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

[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.15.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 template for 'fetchmail' made available

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

Hello, gentle maintainer.

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

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

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

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

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

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

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

Thank you for all your work,

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

[fetchmail-devel] fetchmail 6.3.15-beta3 tests needed - your chance to help!

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

Greetings,

#1 I am asking interested fetchmail users to test a BETA release of
fetchmail.  This beta3 should particularly be tested for portability to
your favourite Unix-like operating system.  It is known to compile on
FreeBSD 8, NetBSD 5, Ubuntu Linux 8.04, 9.10, 10.04 alpha, openSUSE
11.2, Solaris 10, but it may break on other operating systems where it
used to work.

   If this beta either stops or continues being compilable for you for an
operating system not listed above, please report your findings. In case
of success, please report "uname -a" (or otherwise operating system
details such as processor architecture, OS vendor, name and version).
In case of failure, please report that and the build logs, along with
config.h and config.log files.

#2 Also, if you can offer access to test servers that I can send a short
test mail to and then log into to retrieve that test message -
particularly Exchange 2007 is desired, but others besides Cyrus IMAP and
Dovecot are also welcome - please let me know.

#3 Finally, fetchmail needs translators for the program strings. Some
languages (such as those shown below) are in quite good shape, but
others are lacking a bit.

Translation information at
<http://translationproject.org/domain/fetchmail.html>



DOWNLOAD this beta software from:
<http://home.pages.de/~mandree/fetchmail/>

The repository can be browsed at and cloned from:
<http://gitorious.org/fetchmail/fetchmail>

Git (the software used to keep the fetchmail source code version
controlled) information is at: <http://git-scm.com/>

CHANGES since the previous formal release of fetchmail listed below.
Unless otherwise noted, the changes were made by Matthias Andree:

# FEATURE
* Fetchmail now supports a bad-header command line or rcfile option that takes
  exactly one argument, accept or reject (default).  This specifies how messages
  with bad headers retrieved from the current server are to be treated.

# BUG FIXES
* In the rcfile, recognize "local" as abbreviation for "localdomains", as
  documented. The short form has not ever worked since this feature was added in
  January 1997. Reported by Frédéric Marchal.
* Do not close stdout when using mda and "bsmtp -" at the same time.
* Log operating system errors when BSMTP writes fail.
* Fix verbose mode progress formatting regression from 6.3.10; SMTP trace lines
  were no longer on a line of their own. Reported by Melchior Franz.
* Check seteuid() return value and abort running MDA if switch fails.
* Set global flags in a consistent manner. Make --nosoftbounce and
  --nobounce work from command line (these used to work in rcfiles).
  Reported and fix confirmed working by N.J. Mann. (Sunil Shetye)
* Properly import h_errno declarations, even on systems where h_errno isn't a
  macro. (Adds ./configure check, fixes Cygwin dllimport warnings.)

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

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

# TRANSLATION UPDATES, by language name
* [zh_CN] Chinese (Simplified), by Ji Zheng-Yu
* [cs]    Czech, by Petr Pisar
* [nl]    Dutch, by Erwin Poeze
* [fr]    French, by Frédéric Marchal
* [de]    German
* [id]    Indonesian, by Andhika Padmawan
* [it]    Italian, by Vincenzo Campanella
* [ja]    Japanese, by Takeshi Hamasaki
* [pl]    Polish, by Jakub Bogusz
* [vi]    Vietnamese, by Clytie Siddall

-- 
Matthias Andree