fetchmail-devel — Development related discussion

[fetchmail-devel] [Bug #16000] fetchmail should support multiple sslfingerprint's

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

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

Project: Community Fetchmail
Category: None
Status: Closed
Resolution: Invalid
Bug Group: None
Priority: 5
Submitted by: jw9
Assigned to : none
Summary: fetchmail should support multiple sslfingerprint's

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: 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 #16000] fetchmail should support multiple sslfingerprint's

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

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

Project: Community Fetchmail
Category: None
Status: Closed
Resolution: Invalid
Bug Group: None
Priority: 5
Submitted by: jw9
Assigned to : none
Summary: fetchmail should support multiple sslfingerprint's

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: 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 #16000] fetchmail should support multiple sslfingerprint's

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

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

Project: Community Fetchmail
Category: None
Status: Closed
Resolution: Invalid
Bug Group: None
Priority: 5
Submitted by: jw9
Assigned to : none
Summary: fetchmail should support multiple sslfingerprint's

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: 2009-Jul-16 23: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 22: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 21: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 21: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 21: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 20: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 #16000] fetchmail should support multiple sslfingerprint's

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

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

Project: Community Fetchmail
Category: None
Status: Closed
Resolution: Invalid
Bug Group: None
Priority: 5
Submitted by: jw9
Assigned to : none
Summary: fetchmail should support multiple sslfingerprint's

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: 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 #16000] fetchmail should support multiple sslfingerprint's

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

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

Project: Community Fetchmail
Category: None
Status: Closed
Resolution: Invalid
Bug Group: None
Priority: 5
Submitted by: jw9
Assigned to : none
Summary: fetchmail should support multiple sslfingerprint's

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: 2009-Jul-16 21: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 21: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 21: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 20: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 #16000] fetchmail should support multiple sslfingerprint's

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

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

Project: Community Fetchmail
Category: None
Status: Closed
Resolution: Invalid
Bug Group: None
Priority: 5
Submitted by: jw9
Assigned to : none
Summary: fetchmail should support multiple sslfingerprint's

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: 2009-Jul-16 21: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 21: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 20: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 #16000] fetchmail should support multiple sslfingerprint's

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

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

Project: Community Fetchmail
Category: None
Status: Closed
Resolution: Invalid
Bug Group: None
Priority: 5
Submitted by: jw9
Assigned to : none
Summary: fetchmail should support multiple sslfingerprint's

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: 2009-Jul-16 21: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 20: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 #16000] fetchmail should support multiple sslfingerprint's

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

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

Project: Community Fetchmail
Category: None
Status: Closed
Resolution: Invalid
Bug Group: None
Priority: 5
Submitted by: jw9
Assigned to : none
Summary: fetchmail should support multiple sslfingerprint's

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: 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 #16000] fetchmail should support multiple sslfingerprint's

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

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

Project: Community Fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: jw9
Assigned to : none
Summary: fetchmail should support multiple sslfingerprint's

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.


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

Re: [fetchmail-devel] fetchmail and mapi II

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

Am 09.07.2009, 06:43 Uhr, schrieb Yangyan Li <yan...@gm...>:

> Sorry for the messing up of branch MAPI, I will try to fix these
> issues one by one.

That sounds great. Thank you!

> Roughly speaking, I will concentrate on:
> 1. a complete review of the existing code, probably a rewriting is  
> required.
> 2. port this branch to match the latest libmapi release.
>
> In fact, I test on the Exchange Server inside my Virtualbox, it will
> be great if anyone can provide some testing environments.
>
> I will seek more advice from you during my development and welcome  
> opinions!

You're welcome to use the fetchmail-devel@ list for further questions. Use  
"MAPI" in the subject so that all interested parties will see your  
messages.

CONTENTS

I have merged the 6.3.10 release (from /branches/BRANCH_6-3) into  
BRANCH_MAPI, and merged Mojmir's patches where they looked sane, and fixed  
some minor configure.ac issues (see NEWS).

Do we really need libmagic for MAPI support? What exactly does it do?


SUBVERSION CHANGES

WRT the Subversion server:  I have had Graham (who maintains the server)  
enable mergeinfo tracking. The server now also locks out commits from SVN  
clients that are older than version 1.5.0, to make sure that no clients  
mess up the mergeinfo. (The server is version 1.6.X).

The bonus is that you no longer need to manually track which version you  
have merged, Subversion does that for you. It can't hurt to document the  
version, as you used to do :). Just make sure to only use "svn merge [-c  
M[,N...] | -r N:M ...] SOURCE[@REV] [WCPATH]" syntax.

If this feature is new for you, and you're looking for documentation, see  
for instance  
http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html and  
the following sections and chapters.


COMPILE WITH WARNINGS

Could I ask you a favour? Can you configure with modified CFLAGS, for  
instance:

configure -C --with-ssl --enable-MAPI CFLAGS="-O -g -pipe -Wall -W -Wextra  
-pedantic"

(-W -Wextra is redundant, but covers older and newer GCC versions)

That enables some more warnings and helps find bugs - for instance, I  
found the sprintf() bug (around language code parsing) in rcfile_y.y that  
way.

Warnings of the "defined but not used" need not be fixed if you're sure  
that you haven't mistyped somewhere and actually meant to use the unused  
variables.

Signedness warnings should be double-checked and fixed by matching types -  
please do not add casts to silence the compiler!  These warnings are  
usually hints that something's wrong with the code, and a second thought  
needs to be spent especially on indexes and wraparound/overflow behaviour.


Thanks again!

Best regards

-- 
Matthias Andree

Re: [fetchmail-devel] fetchmail and mapi II

[Yangyan Li <yan...@gm...>]

Hi Matthias,

Sorry for the messing up of branch MAPI, I will try to fix these
issues one by one.

Roughly speaking, I will concentrate on:
1. a complete review of the existing code, probably a rewriting is required.
2. port this branch to match the latest libmapi release.

In fact, I test on the Exchange Server inside my Virtualbox, it will
be great if anyone can provide some testing environments.

I will seek more advice from you during my development and welcome opinions!

Best Regards!
Yangyan

On Tue, Jul 7, 2009 at 5:09 AM, Matthias Andree<mat...@gm...> wrote:
> Am 16.06.2009, 17:55 Uhr, schrieb mojmir svoboda
> <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
>
> Hi Mojmir,
>
> I have updated fetchmail's BRANCH_MAPI branch to release 6.3.10 including
> the post-release updates to Spanish and Chinese translations as of
> yesterday.
>
> I have merged your mapi2.patch (thanks), but haven't yet had the time to
> look at the messages or other problems we discussed.
>
> I fixed an issue in rcfile_y.y where the LCID parsing for strings that
> didn't start with 0x was utterly broken.
>
> I fixed configure.ac logic so that --disable-MAPI (or not specifying this)
> works, and we only check for libmagic if needed.
>
> So me new issues I discovered that also need addressing:
>
> - all issues you've mentioned that haven't been addressed by your patch, for
> instance, message corruption as observed, or duplication of base64 encoders.
>
> - there are warnings about broken 4th arguments to one of the openchange
> functions
>
> - mapi.c throws a zillion of warnings of mismatched signedness in
> comparisons, or unused variables. All have to be audited that they don't
> trigger integer overflows or negative indexes.
>
> - the MAPI code adds quite a few if (blah.protocol != P_MAPI) ... #ifdef
> MAPI_ENABLE ... #endif that should be abstracted away rather than copy &
> paste code...
>
> - the bug I fixed in rcfile_y.y was sort of target = sprintf("0x%04x",
> uint32_t); - oops. sprintf takes the output variable as argument and returns
> the length... I hope there isn't more of this bug.
>
> - more will show up as fixup and integration proceed.
>
>
> For better or for worse, the current BRANCH_MAPI code isn't currently fit
> for integration into the trunk, but needs considerable work. With the most
> recent commits, I can compile it on openSUSE 11.1 with the -devel packages
> from
> http://download.opensuse.org/repositories/GNOME:/Evolution:/mapi/openSUSE_11.1
> and with file-devel installed (that is the openSUSE package containing
> libmagic development files), if I run
>
> ./autogen.sh
> mkdir build
> cd build
> PKG_CONFIG_PATH=/usr/lib/samba4/lib/pkgconfig/ \
> ../configure -C --enable-MAPI --with-ssl \
> CFLAGS="-O -pipe -ggdb3 -Wall -Wextra -W" \
> && make -sj4
>
> You can check out sources from
> http://mknod.org/svn/fetchmail/branches/BRANCH_MAPI/
>
>
> I'm not interested in doing any of the audit/cleanup/fixup work as assessed
> in this and related threads, but I am happy to help with the integration
> later and help with tracing the requirements.
>
> Reasons are that I personally do not have interest in MAPI support, I have
> no Exchange server to test (Asif Iqbal offered help with testing, but I
> think the tests should be done by those who fix up the code). If someone is
> willing to pay pro rates, can provide an Exchange server to test against, be
> happy with low-profile effort (5 - 20 hours per month - not week!) that can
> start only in a few months' time, contact me off-list. No promises though.
>
> So - any volunteers to audit and/or polish BRANCH_MAPI?
>
> Thanks in advance
>
> --
> Matthias Andree
>

Re: [fetchmail-devel] Fetchmail & Yahoo

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

Am 30.06.2009, 12:42 Uhr, schrieb Valentin Manea <fet...@mr...>:


> Hi Matthias,
>
>    Seems the problem you are referring to is caused by fetchmail not
> being able to delete the message, in the beginning for me it just
> downloaded one message and then started complaining about message size.
> Because of this I've just added the keep directive to fetchmailrc, which
> looks like this now:
> poll imap.next.mail.yahoo.com with proto IMAP
>       user '************' with pass "********" is '*********' here
>       options ssl smtphost localhost keep;
>    This configuration has worked fine for me for over a week.
>
>    As for the server, it seems you can use *imap.mail.yahoo.com* as well.

Well... I think the major issue is that if you aren't using another  
client, marking a message \Seen also causes failure retrieving subsequent  
messages. The code above was (accidentally) made part of fetchmail 6.3.10,  
but I'll not be supporting it. I'm not interested in working around this  
half-baked Yahoo IMAP stuff.

I'm not going to pursue this Yahoo-IMAP any further. If someone's  
interested, talk to Yahoo first if they plan to fix their server for IMAP  
compliance...

-- 
Matthias Andree

Re: [fetchmail-devel] fetchmail and mapi II

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

Am 16.06.2009, 17:55 Uhr, schrieb mojmir svoboda  
<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

Hi Mojmir,

I have updated fetchmail's BRANCH_MAPI branch to release 6.3.10 including  
the post-release updates to Spanish and Chinese translations as of  
yesterday.

I have merged your mapi2.patch (thanks), but haven't yet had the time to  
look at the messages or other problems we discussed.

I fixed an issue in rcfile_y.y where the LCID parsing for strings that  
didn't start with 0x was utterly broken.

I fixed configure.ac logic so that --disable-MAPI (or not specifying this)  
works, and we only check for libmagic if needed.

So me new issues I discovered that also need addressing:

- all issues you've mentioned that haven't been addressed by your patch,  
for instance, message corruption as observed, or duplication of base64  
encoders.

- there are warnings about broken 4th arguments to one of the openchange  
functions

- mapi.c throws a zillion of warnings of mismatched signedness in  
comparisons, or unused variables. All have to be audited that they don't  
trigger integer overflows or negative indexes.

- the MAPI code adds quite a few if (blah.protocol != P_MAPI) ... #ifdef  
MAPI_ENABLE ... #endif that should be abstracted away rather than copy &  
paste code...

- the bug I fixed in rcfile_y.y was sort of target = sprintf("0x%04x",  
uint32_t); - oops. sprintf takes the output variable as argument and  
returns the length... I hope there isn't more of this bug.

- more will show up as fixup and integration proceed.


For better or for worse, the current BRANCH_MAPI code isn't currently fit  
for integration into the trunk, but needs considerable work. With the most  
recent commits, I can compile it on openSUSE 11.1 with the -devel packages  
 from  
http://download.opensuse.org/repositories/GNOME:/Evolution:/mapi/openSUSE_11.1  
and with file-devel installed (that is the openSUSE package containing  
libmagic development files), if I run

./autogen.sh
mkdir build
cd build
PKG_CONFIG_PATH=/usr/lib/samba4/lib/pkgconfig/ \
../configure -C --enable-MAPI --with-ssl \
CFLAGS="-O -pipe -ggdb3 -Wall -Wextra -W" \
&& make -sj4

You can check out sources from  
http://mknod.org/svn/fetchmail/branches/BRANCH_MAPI/


I'm not interested in doing any of the audit/cleanup/fixup work as  
assessed in this and related threads, but I am happy to help with the  
integration later and help with tracing the requirements.

Reasons are that I personally do not have interest in MAPI support, I have  
no Exchange server to test (Asif Iqbal offered help with testing, but I  
think the tests should be done by those who fix up the code). If someone  
is willing to pay pro rates, can provide an Exchange server to test  
against, be happy with low-profile effort (5 - 20 hours per month - not  
week!) that can start only in a few months' time, contact me off-list. No  
promises though.

So - any volunteers to audit and/or polish BRANCH_MAPI?

Thanks in advance

-- 
Matthias Andree

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

[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-pre2.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 Chinese (simplified) PO file for 'fetchmail' (version 6.3.10-pre2)

[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-pre2.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 Spanish PO file for 'fetchmail' (version 6.3.10-pre2)

[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-pre2.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 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.10-pre2.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.10.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.10 release available (STABLE)

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

Greetings,

I am announcing the release of fetchmail 6.3.10.
This new stable version of fetchmail fixes some bugs, updates
documentation, and makes various other changes, see below for details.

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

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

These are the relevant changes in 6.3.10 since 6.3.9;
unless otherwise noted, changes to this release were made by Matthias Andree:

# ADVANCE WARNING OF FEATURES TO BE REMOVED OR CHANGED IN FUTURE VERSIONS
(There are no plans to remove features from a 6.3.X release, but they may be
removed from a 6.4.0 or newer release.)
* The MX and host alias DNS lookups that fetchmail performs in multidrop mode
  are based on assumptions that are rarely met in practice, somewhat defective,
  deprecated and may be removed from a future fetchmail version.
  They have never supported IPv6 (including IPv6-mapped IPv4).
  Non-DNS based alias keywords such as "aka" will remain in fetchmail.
* The monitor and interface options may be removed from a future fetchmail
  version as they are not reasonably portable across operating systems.
* POP2 is obsolete, support will be removed from a future fetchmail version.
* RPOP is obsolete, support will be removed from a future fetchmail release.
* --sslcertck will become a default setting in a future fetchmail version.
* The multidrop To/Cc guessing code along with the fragile duplicate suppressor
  is deprecated and may be removed from a future release.
* The "envelope Received" option may be removed from a future release, because
  the Received header was never meant to be machine-readable, the format varies
  widely, and various other differences in behavior make parsing Received an
  unreliable undertaking. The envelope option as such will remain though, in
  order to support Delivered-To, X-Envelope-To, X-Original-To and similar.
  See also <http://home.pages.de/~mandree/mail/multidrop>.
* The --enable-fallback (fall back to MDA if MTA unavailable) will be removed
  from a future fetchmail release, because it makes fetchmail's behavior
  inconsistent and confusing.
* The "protocol auto" default inside fetchmail may be removed from a future
  fetchmail release. Explicit configuration of the protocol is recommended.
* Kerberos IV support may be removed from a future fetchmail release.
* SIGHUP wakeup support may be removed from a future fetchmail release and
  cause fetchmail to terminate - it was broken for many years.
* Support for operating systems that are not sufficiently POSIX compliant may be
  removed or operation on such systems may be suboptimal for future releases.
  This means that fetchmail may only continue to work on C99 and POSIX 2001
  based systems.
* The maintainer may migrate fetchmail to C++ with STL or C#, and impose further
  requirements (dependencies), such as Boost or other class libraries.
* The softbounce option default will change to "false" in the next release.

# INCOMPATIBLE BUGFIXES AND CHANGES
* Fetchmail no longer drops permanently undelivered messages by default, to
  match historic documentation.  It does this by adding a new "softbounce"
  option, see below.
  Fixes Debian Bug#471283, demotes Debian Bug#494418 to wishlist.
* There is a new "softbounce" global option that prevents the deletion of
  messages that have not been forwarded. It defaults to "true" for fetchmail
  6.3.X in order to match historic documentation. This may change its default
  in the next major release.

# BUGFIXES
* Fix misuse of canonical autoconf target as _TARGET when it should have been
  _HOST. Report and patch courtesy of Diego E. "Flameeyes" Pettenò.
  Details: http://blog.flameeyes.eu/2009/01/01/the-canonical-target
* Do not lose PS_MAXFETCH (13) exit status when hitting maxpoll. Reported by
  Michelle Konzack, Debian Bug#508667.
* Do not overlap source and destination fields in snprintf() in interface.c.
  Courtesy of Nico Golde, Debian.
* When a pre- or post-connect command fails, now report the exit status or
  termination signal properly through sys/wait.h macros.
* When acquiring a body, understand NIL ("no such data item"), as returned by
  some MS Exchange versions. Fixes BerliOS Bug #11980 by KB Sriram.
* Make progress tickers (-v/--showdots) consistent, and update documentation 
  accordingly ("." for each 1024 octets read, "#" for a header written, and "*" 
  for each body line written.)
  The conditions under which these had been printed were inconsistent,
  illogical, and documentation hadn't matched real behaviour for long.
* For NTLM authentication, use dynamically allocated buffers.
  Fixes Debian Bug#449179, reported by Stepan Golosunov.
* Non-delivery notice ("bounce mail") now mentions the original reason again,
  before the address list. This fixes a regression introduced in 6.3.0.
* Several compiler warnings were fixed.
* The minimum recommended SMTP (RFC-5321) timeouts are enforced to leave
  sufficient time for the listener to respond. Some synchronous listeners,
  particularly when used with spam filtering and other policy enforcement
  services, take extended amounts of time to process messages after the sender,
  recipient, or data block and EOM line. This can cause fetchmail to not wait
  long enough for the "250 Ok" and make fetchmail believe the message wasn't
  properly delivered when in fact it was; fetchmail would then retry the
  download next time and never make progress.
  Fixes Berlios Bug #10972, reported by Viktor Binzberger.
* The ESMTP/LMTP client will now apply an application-specific timeout while
  waiting for the EHLO/LHLO response, rather than wait for the server or TCP
  connection timeout.
* Treat 530 errors as temporary, so as not to delete messages on configuration
  errors. Partially taken from Petr Cerny's patch in Novell Bugzilla #246829.
  The 501 part of said patch was not added, as the maintainer is not convinced
  501 is a temporary condition, and softbounce takes care of this anyways.

# CHANGES
* Make the comparison of the SSL fingerprints case insensitive, to
  ease its use. Suggested by Daniel Richard G.
* Proper precedence ordering for the syslog and logfile options. If the logfile
  option is effective (i. e. we're not in daemon mode and nodetach isn't used),
  reset the syslog option. If logfile is ineffective (we're not in daemon mode,
  or nodetach is set), syslog takes precedence.
* The sleeping at/awakened at messages appear in logfiles and syslog only if
  verbose mode is enabled.  On the console, they will still appear without
  verbose mode.  Fixes Debian Bug#282259.
* fetchmail only requests IPv6 addresses via name service if at least one is
  configured on the local host, likewise for IPv4.  (AI_ADDRCONFIG flag to
  getaddrinfo()) Extended version of Redhat's patch.
* If the server name contains "yahoo.com", offers the "ID" capability, and we're
  polling via IMAP, send an ID ("guid" "1") transaction first, ignoring its
  result. This appears needed to be able to log into Yahoo's Zimbra servers, but
  there are open issues (such as being only able to download one message and
  server certificate mismatches).

# CHANGES TO CONTRIB
* Fix bashism in contrib/fetchsetup. Fixes Debian Bug#530081.

# DOCUMENTATION
* Some parts of the the manual page were revised for clarity, accuracy, and
  updated recommendations (particularly SSL/TLS) and formatting conventions from
  man-pages(7).
* The README and README.SSL documents were updated.
* A document, README.SSL-SERVER, was added to describe server-side requirements
  for proper SSL and/or TLS service offerings. These are not specific to
  fetchmail.
* Documentation on how to make "NOMAIL" (exit code 1) not treated an error has
  been added to the EXIT CODES section of the manpage and to the FAQ as item C8.
  The suggested solution uses a tiny POSIX shell script fragment.
  Fixes Debian Bug #530749, filed by Reuben Thomas.

# TRANSLATION UPDATES AND ADDITIONS (ordered by language name):
* [cs]    Czech (Petr Pisar)
* [en_GB] English/British
* [de]    German
* [id]    Indonesian (Andhika Padmawan)
* [it]    Italian (Vincenzo Campanella)
* [ja]    Japanese (Takeshi Hamasaki)
* [pl]    Polish (Jakub Bogusz)
* [ru]    Russian (Pavel Maryanov), fixing Debian Bug #531925
* [es]    Spanish/Castilian (Francisco Molinero)
* [zh_CN] Chinese/Simplified (Ji ZhengYu)

-- 
Matthias Andree

[fetchmail-devel] mapi

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

hello again

i am very sorry, i haven't got much time these days (oh you certainly
know how activity increases when finish approaches), but i keep in mind
that this mapi i am using right now is half-baked and still willing to
fix some of the nastiest behaviours (if not bugs).

meanwhile i'd like to ask about the form of our collaboration. i took a
look on the code, and there's a lot of work "here and there" and
therefore i simply cannot supply simple patches, as i change things as
walking around (damn i am a philosopher now;)

i know that many opensource projects requires signing some papers with
fsf when the patches are not trivial. is this the case?

best regards,
mojmir

Re: [fetchmail-devel] Fetchmail & Yahoo

[Valentin M. <fet...@mr...>]

On 06/30/2009 11:56 AM, Matthias Andree wrote:
> Am 23.06.2009, 10:56 Uhr, schrieb Valentin Manea<fet...@mr...>:
>
>    
>>     This has been hunting me for a while now but it seems after Yahoo
>> released Zimbra it is possible to get your email from Yahoo without
>> those ugly solutions. The catch is that before authentication you have
>> to send a custom command to the server. I've made a small change in
>> imap.c and now finally I can use fetchmail with my free yahoo account.
>> As I'm not that familiar with the developing for fetchmail I would
>> really not send a patch but only describe what I did.
>>
>>     So I've just added this line:
>> gen_transact(sock, "ID (\"guid\" \"1\")");
>> in *imap_getauth* after the SSL stuf. This doesn't seem to affect normal
>> IMAP servers in any way.
>>      
>
> Hi Valentin,
>
> I've tried this, and it works to some extent.
>
> On the first attempt, I could only download one message (which fetchmail
> marked \Seen). After that, the server would complain "NO mailbox was
> modified" on all subsequent messages I tried to download... have you
> observed such behaviour?
>
> Beyond that, fetchmail in verbose mode complains about size mismatches,
> namely that messages didn't have the expected size. I haven't yet
> investigated what causes this.
>
> Finally, I don't know the proper IMAP-SSL server name.
> imap-ssl.mail.yahoo.com gives me the connection, but the certificate is
> issued for *.imap.mail.yahoo.com, so I get complaints about invalid
> certificates.
>
> I'm currently testing this patch (also attached) which only tries this
> nnn ID ("guid" "1") on yahoo.com servers, but it's not ready for
> inclusion for the reasons above:
>
> diff --git a/imap.c b/imap.c
> index 5347492..54309f7 100644
> --- a/imap.c
> +++ b/imap.c
> @@ -478,6 +478,15 @@ static int imap_getauth(int sock, struct query *ctl, char *greeting)
>        */
>       ok = PS_AUTHFAIL;
>
> +    /* Yahoo hack - we'll just try ID if it was offered by the server,
> +     * and IGNORE errors. */
> +    {
> +	char *tmp = strstr(capabilities, " ID");
> +	if (tmp&&  !isalnum(tmp[3])&&  strstr(ctl->server.via ? ctl->server.via : ctl->server.pollname, "yahoo.com")) {
> +		(void)gen_transact(sock, "ID (\"guid\" \"1\")");
> +	}
> +    }
> +
>       if ((ctl->server.authenticate == A_ANY
>            || ctl->server.authenticate == A_EXTERNAL)
>   	&&  strstr(capabilities, "AUTH=EXTERNAL"))
>
> Best regards
> Matthias
>    
Hi Matthias,

   Seems the problem you are referring to is caused by fetchmail not 
being able to delete the message, in the beginning for me it just 
downloaded one message and then started complaining about message size. 
Because of this I've just added the keep directive to fetchmailrc, which 
looks like this now:
poll imap.next.mail.yahoo.com with proto IMAP
      user '************' with pass "********" is '*********' here
      options ssl smtphost localhost keep;
   This configuration has worked fine for me for over a week.

   As for the server, it seems you can use *imap.mail.yahoo.com* as well.

PS: Sorry about the spam, but Thunderbird 3b2 really sucks at replies :-)

Best Regards,
Valentin

Re: [fetchmail-devel] Fetchmail & Yahoo

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

Am 23.06.2009, 10:56 Uhr, schrieb Valentin Manea <fet...@mr...>:

>    This has been hunting me for a while now but it seems after Yahoo
> released Zimbra it is possible to get your email from Yahoo without
> those ugly solutions. The catch is that before authentication you have
> to send a custom command to the server. I've made a small change in
> imap.c and now finally I can use fetchmail with my free yahoo account.
> As I'm not that familiar with the developing for fetchmail I would
> really not send a patch but only describe what I did.
>
>    So I've just added this line:
> gen_transact(sock, "ID (\"guid\" \"1\")");
> in *imap_getauth* after the SSL stuf. This doesn't seem to affect normal
> IMAP servers in any way.

Hi Valentin,

I've tried this, and it works to some extent.

On the first attempt, I could only download one message (which fetchmail
marked \Seen). After that, the server would complain "NO mailbox was
modified" on all subsequent messages I tried to download... have you
observed such behaviour?

Beyond that, fetchmail in verbose mode complains about size mismatches,
namely that messages didn't have the expected size. I haven't yet
investigated what causes this.

Finally, I don't know the proper IMAP-SSL server name.
imap-ssl.mail.yahoo.com gives me the connection, but the certificate is
issued for *.imap.mail.yahoo.com, so I get complaints about invalid
certificates.

I'm currently testing this patch (also attached) which only tries this
nnn ID ("guid" "1") on yahoo.com servers, but it's not ready for
inclusion for the reasons above:

diff --git a/imap.c b/imap.c
index 5347492..54309f7 100644
--- a/imap.c
+++ b/imap.c
@@ -478,6 +478,15 @@ static int imap_getauth(int sock, struct query *ctl, char *greeting)
      */
     ok = PS_AUTHFAIL;
 
+    /* Yahoo hack - we'll just try ID if it was offered by the server,
+     * and IGNORE errors. */
+    {
+	char *tmp = strstr(capabilities, " ID");
+	if (tmp && !isalnum(tmp[3]) && strstr(ctl->server.via ? ctl->server.via : ctl->server.pollname, "yahoo.com")) {
+		(void)gen_transact(sock, "ID (\"guid\" \"1\")");
+	}
+    }
+
     if ((ctl->server.authenticate == A_ANY 
          || ctl->server.authenticate == A_EXTERNAL)
 	&& strstr(capabilities, "AUTH=EXTERNAL"))

Best regards
Matthias

-- 
Matthias Andree

Re: [fetchmail-devel] Fetchmail & Yahoo

[Valentin M. <fet...@mr...>]

-------- Original Message --------
Subject: 	Re: [fetchmail-devel] Fetchmail & Yahoo
Date: 	Wed, 24 Jun 2009 15:44:59 +0300
From: 	Valentin Manea <fet...@mr...>
To: 	Matthias Andree <mat...@gm...>





On 06/23/2009 04:38 PM, Matthias Andree wrote:
> Valentin Manea schrieb:
>
>    
>>     This has been hunting me for a while now but it seems after Yahoo
>> released Zimbra it is possible to get your email from Yahoo without
>> those ugly solutions. The catch is that before authentication you have
>> to send a custom command to the server. I've made a small change in
>> imap.c and now finally I can use fetchmail with my free yahoo account.
>> As I'm not that familiar with the developing for fetchmail I would
>> really not send a patch but only describe what I did.
>>      
>
>    
>>     So I've just added this line:
>> gen_transact(sock, "ID (\"guid\" \"1\")");
>> in *imap_getauth* after the SSL stuf. This doesn't seem to affect normal
>> IMAP servers in any way.
>>      
>
> Where would I look for documentation for this Yahoo IMAP server requirement, or
> how else have you found out what was needed? Is this "1" really a constant?
> Technically, it seems to be RFC-2971 and if the Zimbra server side, or Yahoo's
> deployment, actually requires this, it is a RFC-2971 violation, see the "MUST
> NOT" clauses in section 3 of said RFC.
>
> Does it work to send . ID NIL?
> I should rather not like to send random data there unless needed, and GUID
> raises some suspicions...
>
> Thank you&  best regards
> Matthias Andree
>    
Damned Reply, once more with the correct address:

There is no documentation, I've just sniffed an older Zimbra Desktop 
which did not use SSL.

You are right, it is not RFC-2971 because I'm unable to login using ID 
NIL and also it doesn't seem to accept other tags. Also *1* does not 
seem to be a constant, I've tried some random numbers and I was still 
able to login.

Best Regards,
Valentin

Re: [fetchmail-devel] Fetchmail & Yahoo

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

Valentin Manea schrieb:

>    This has been hunting me for a while now but it seems after Yahoo 
> released Zimbra it is possible to get your email from Yahoo without 
> those ugly solutions. The catch is that before authentication you have 
> to send a custom command to the server. I've made a small change in 
> imap.c and now finally I can use fetchmail with my free yahoo account. 
> As I'm not that familiar with the developing for fetchmail I would 
> really not send a patch but only describe what I did.

>    So I've just added this line:
> gen_transact(sock, "ID (\"guid\" \"1\")");
> in *imap_getauth* after the SSL stuf. This doesn't seem to affect normal 
> IMAP servers in any way.

Where would I look for documentation for this Yahoo IMAP server requirement, or
how else have you found out what was needed? Is this "1" really a constant?
Technically, it seems to be RFC-2971 and if the Zimbra server side, or Yahoo's
deployment, actually requires this, it is a RFC-2971 violation, see the "MUST
NOT" clauses in section 3 of said RFC.

Does it work to send . ID NIL?
I should rather not like to send random data there unless needed, and GUID
raises some suspicions...

Thank you & best regards
Matthias Andree

[fetchmail-devel] Fetchmail & Yahoo

[Valentin M. <fet...@mr...>]

Hi All,

   This has been hunting me for a while now but it seems after Yahoo 
released Zimbra it is possible to get your email from Yahoo without 
those ugly solutions. The catch is that before authentication you have 
to send a custom command to the server. I've made a small change in 
imap.c and now finally I can use fetchmail with my free yahoo account. 
As I'm not that familiar with the developing for fetchmail I would 
really not send a patch but only describe what I did.

   So I've just added this line:
gen_transact(sock, "ID (\"guid\" \"1\")");
in *imap_getauth* after the SSL stuf. This doesn't seem to affect normal 
IMAP servers in any way.

Hope this helps someone,
Vali

[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