Re: [gentoo-user] fetchmail + certs = problems
On Sat, Oct 02, 2010 at 12:31:38PM +0200, meino.cra...@gmx.de wrote: Hi, fetchmail's log told me, that there is something wrong with the setup of the certificats. In the log there is the following section fetchmail: Server certificate: fetchmail: Issuer Organization: Thawte Consulting cc fetchmail: Issuer CommonName: Thawte Premium Server CA fetchmail: Subject CommonName: pop.gmx.net fetchmail: pop.gmx.net key fingerprint: A6:57:BC:4A:97:AD:DB:99:00:E9:3A:B8:81:55:D7:B6 fetchmail: Server certificate verification error: unable to get local issuer certificate fetchmail: This means that the root signing certificate (issued for /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=pop.gmx.net) is not in the trusted CA certificate locations, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page. fetchmail: Server certificate: fetchmail: Issuer Organization: Thawte Consulting cc fetchmail: Issuer CommonName: Thawte Premium Server CA fetchmail: Subject CommonName: pop.gmx.net fetchmail: Server certificate verification error: certificate not trusted fetchmail: Server certificate: fetchmail: Issuer Organization: Thawte Consulting cc fetchmail: Issuer CommonName: Thawte Premium Server CA fetchmail: Subject CommonName: pop.gmx.net fetchmail: Server certificate verification error: unable to verify the first certificate fetchmail: Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!) In beforehand I did the following: i did pretty much the same thing without success :( but the sslcertfile option in the default section of my .fetchmailrc finaly solved the problem: he...@chiefwiggum:~ cat .fetchmailrc defaults proto pop3 limit 0 mda /usr/bin/procmail -d %T sslcertfile /etc/ssl/certs/ca-certificates.crt poll pop.1und1.de user xxx keep ssl poll pop.gmx.net user xxx keep ssl option sslcertfile in the fetchmail manpage and the update-ca-certificates manpage gave me the hint. cheers heiko -- This email is not and cannot, by its nature, be confidential. En route from me to you, it will pass across the public Internet, easily readable by any number of system administrators along the way. If you have received this message by mistake, it would be ridiculous for me to tell you not to read it or copy to anyone else, because, let's face it, if it's a message revealing confidential information or that could embarrass me intensely, that's precisely what you'll do. Who wouldn't? Likewise, it is superfluous for me to claim copyright in the contents, because I own that anyway, even if you print out a hard copy or disseminate this message all over the known universe. I don't know why so many corporate mail servers feel impelled to attach a disclaimer to the bottom of every email message saying otherwise. If you don't know either, why not email your corporate lawyers and system administrators and ask them why they insist on contributing so much to the waste of bandwidth? To say nothing of making the presence of your mail on public discussions or mailinglists of explicitly contratictory nature. May as well just delete it, eh? Oh, and this message is probably plagued with viruses as well. pgp8wdHnW3hk1.pgp Description: PGP signature
Re: [gentoo-user] fetchmail + certs = problems
Heiko Zinke ma...@rabuju.com [10-10-03 22:01]: On Sat, Oct 02, 2010 at 12:31:38PM +0200, meino.cra...@gmx.de wrote: Hi, fetchmail's log told me, that there is something wrong with the setup of the certificats. In the log there is the following section fetchmail: Server certificate: fetchmail: Issuer Organization: Thawte Consulting cc fetchmail: Issuer CommonName: Thawte Premium Server CA fetchmail: Subject CommonName: pop.gmx.net fetchmail: pop.gmx.net key fingerprint: A6:57:BC:4A:97:AD:DB:99:00:E9:3A:B8:81:55:D7:B6 fetchmail: Server certificate verification error: unable to get local issuer certificate fetchmail: This means that the root signing certificate (issued for /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=pop.gmx.net) is not in the trusted CA certificate locations, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page. fetchmail: Server certificate: fetchmail: Issuer Organization: Thawte Consulting cc fetchmail: Issuer CommonName: Thawte Premium Server CA fetchmail: Subject CommonName: pop.gmx.net fetchmail: Server certificate verification error: certificate not trusted fetchmail: Server certificate: fetchmail: Issuer Organization: Thawte Consulting cc fetchmail: Issuer CommonName: Thawte Premium Server CA fetchmail: Subject CommonName: pop.gmx.net fetchmail: Server certificate verification error: unable to verify the first certificate fetchmail: Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!) In beforehand I did the following: i did pretty much the same thing without success :( but the sslcertfile option in the default section of my .fetchmailrc finaly solved the problem: he...@chiefwiggum:~ cat .fetchmailrc defaults proto pop3 limit 0 mda /usr/bin/procmail -d %T sslcertfile /etc/ssl/certs/ca-certificates.crt poll pop.1und1.de user xxx keep ssl poll pop.gmx.net user xxx keep ssl option sslcertfile in the fetchmail manpage and the update-ca-certificates manpage gave me the hint. cheers heiko Hi Heiko, looks good! ...and works! Thank you for your help! Best regards mcc -- This email is not and cannot, by its nature, be confidential. En route from me to you, it will pass across the public Internet, easily readable by any number of system administrators along the way. If you have received this message by mistake, it would be ridiculous for me to tell you not to read it or copy to anyone else, because, let's face it, if it's a message revealing confidential information or that could embarrass me intensely, that's precisely what you'll do. Who wouldn't? Likewise, it is superfluous for me to claim copyright in the contents, because I own that anyway, even if you print out a hard copy or disseminate this message all over the known universe. I don't know why so many corporate mail servers feel impelled to attach a disclaimer to the bottom of every email message saying otherwise. If you don't know either, why not email your corporate lawyers and system administrators and ask them why they insist on contributing so much to the waste of bandwidth? To say nothing of making the presence of your mail on public discussions or mailinglists of explicitly contratictory nature. May as well just delete it, eh? Oh, and this message is probably plagued with viruses as well.
Re: [gentoo-user] fetchmail + certs = problems
On Saturday 02 October 2010 11:31:38 meino.cra...@gmx.de wrote: Hi, fetchmail's log told me, that there is something wrong with the setup of the certificats. In the log there is the following section fetchmail: Server certificate: fetchmail: Issuer Organization: Thawte Consulting cc fetchmail: Issuer CommonName: Thawte Premium Server CA fetchmail: Subject CommonName: pop.gmx.net fetchmail: pop.gmx.net key fingerprint: A6:57:BC:4A:97:AD:DB:99:00:E9:3A:B8:81:55:D7:B6 fetchmail: Server certificate verification error: unable to get local issuer certificate fetchmail: This means that the root signing certificate (issued for /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=pop.gmx.net) is not in the trusted CA certificate locations, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page. fetchmail: Server certificate: fetchmail: Issuer Organization: Thawte Consulting cc fetchmail: Issuer CommonName: Thawte Premium Server CA fetchmail: Subject CommonName: pop.gmx.net fetchmail: Server certificate verification error: certificate not trusted fetchmail: Server certificate: fetchmail: Issuer Organization: Thawte Consulting cc fetchmail: Issuer CommonName: Thawte Premium Server CA fetchmail: Subject CommonName: pop.gmx.net fetchmail: Server certificate verification error: unable to verify the first certificate fetchmail: Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!) In beforehand I did the following: From the output of this command # openssl s_client -connect pop.gmx.net:995 -showcerts I copied the section -BEGIN CERTIFICATE- MIIDUzCCArygAwIBAgIQDNZUbIDJ5EM+DVSd5AzXOjANBgkqhkiG9w0BAQUFADCB zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl cnZlckB0aGF3dGUuY29tMB4XDTEwMDQyMjAwMDAwMFoXDTEzMDUwOTIzNTk1OVow WDELMAkGA1UEBhMCREUxDzANBgNVBAgTBkJheWVybjEPMA0GA1UEBxQGTXVuaWNo MREwDwYDVQQKFAhHTVggR21iSDEUMBIGA1UEAxQLcG9wLmdteC5uZXQwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMu3VYZP3YqpNweeIp+zIYtAlYL9Nya5hq6j k+ShUtukV1746nqJto70+4oNhCYJ33mMw+vS5fODjuggG+Z1xcL5YU8mUyG2E7fH YkfNtHHMhRntN15ml7Kv3c52kmOI09r2psnlNPkkNx5shneON8jZfXYlqQq5Vq1l Hz+jEjFrAgMBAAGjgaYwgaMwDAYDVR0TAQH/BAIwADBABgNVHR8EOTA3MDWgM6Ax hi9odHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlU2VydmVyUHJlbWl1bUNBLmNy bDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwMgYIKwYBBQUHAQEEJjAk MCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC50aGF3dGUuY29tMA0GCSqGSIb3DQEB BQUAA4GBAF/BVQRh2QOAtH8491d2XIKqdRZNY4OUMh6qccb0xLGNTDx3E4iwoYHc yi2axElQG+7VAEIbDftzfhVUttsPwLI0BM2Nvz6KkwnlrJmt9HuZOjyv9M6szCxX jHqVXkTDtrvRzT3hHTLD63l4PAqAUDpR4Th4N23IyxpgVqmYZwoJ -END CERTIFICATE- into a file pop.gmx.net.pem and copied ths file into /etc/fetchmail/certs Than I downloaded the whole package of root certificates from here https://www.verisign.com/support/thawte-roots.zip unpacked it and copied each *.pem file into /etc/fetchmail/certs also. I renamend the files to not to contain blanks with detox. Then I run as root the command $ c_rehash /etc/fetchmail/certs I checked /etc/fetchmail/certs and found all files being symlinked to something which looks like hash keys (?). c_hash does not submit any error message. After this I added below the poll section of my accounts $HOME/.fetchmailrc the following line: sslcertpath /etc/fetchmail/certs Nonetheless fetchmail complains about local certifcates. What do I have to do to fix this ? Best regards and thank you for any help in advance! mcc Sendmail and I think fetchmail (haven't used the latter yet) do a strict check of certs against a local store. The error above tells you to add to your .fetchmailrc the option of sslcertck. Did you do that? So your .fetchmailrc should show something like: user 'm...@gmx_whatever.com' with pass 123456 is 'mcc' here options ssl sslcertck sslcertpath '/etc/fetchmail/certs' If you have done the above and still does not work then the problem may be that the user you are running fetchmail as does not have read access to your /etc/fetchmail/certs. Change that to a ~/fetchmail/.certs and it should work. HTH. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] fetchmail + certs = problems
Mick michaelkintz...@gmail.com [10-10-02 13:52]: On Saturday 02 October 2010 11:31:38 meino.cra...@gmx.de wrote: Hi, fetchmail's log told me, that there is something wrong with the setup of the certificats. In the log there is the following section fetchmail: Server certificate: fetchmail: Issuer Organization: Thawte Consulting cc fetchmail: Issuer CommonName: Thawte Premium Server CA fetchmail: Subject CommonName: pop.gmx.net fetchmail: pop.gmx.net key fingerprint: A6:57:BC:4A:97:AD:DB:99:00:E9:3A:B8:81:55:D7:B6 fetchmail: Server certificate verification error: unable to get local issuer certificate fetchmail: This means that the root signing certificate (issued for /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=pop.gmx.net) is not in the trusted CA certificate locations, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page. fetchmail: Server certificate: fetchmail: Issuer Organization: Thawte Consulting cc fetchmail: Issuer CommonName: Thawte Premium Server CA fetchmail: Subject CommonName: pop.gmx.net fetchmail: Server certificate verification error: certificate not trusted fetchmail: Server certificate: fetchmail: Issuer Organization: Thawte Consulting cc fetchmail: Issuer CommonName: Thawte Premium Server CA fetchmail: Subject CommonName: pop.gmx.net fetchmail: Server certificate verification error: unable to verify the first certificate fetchmail: Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!) In beforehand I did the following: From the output of this command # openssl s_client -connect pop.gmx.net:995 -showcerts I copied the section -BEGIN CERTIFICATE- MIIDUzCCArygAwIBAgIQDNZUbIDJ5EM+DVSd5AzXOjANBgkqhkiG9w0BAQUFADCB zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl cnZlckB0aGF3dGUuY29tMB4XDTEwMDQyMjAwMDAwMFoXDTEzMDUwOTIzNTk1OVow WDELMAkGA1UEBhMCREUxDzANBgNVBAgTBkJheWVybjEPMA0GA1UEBxQGTXVuaWNo MREwDwYDVQQKFAhHTVggR21iSDEUMBIGA1UEAxQLcG9wLmdteC5uZXQwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMu3VYZP3YqpNweeIp+zIYtAlYL9Nya5hq6j k+ShUtukV1746nqJto70+4oNhCYJ33mMw+vS5fODjuggG+Z1xcL5YU8mUyG2E7fH YkfNtHHMhRntN15ml7Kv3c52kmOI09r2psnlNPkkNx5shneON8jZfXYlqQq5Vq1l Hz+jEjFrAgMBAAGjgaYwgaMwDAYDVR0TAQH/BAIwADBABgNVHR8EOTA3MDWgM6Ax hi9odHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlU2VydmVyUHJlbWl1bUNBLmNy bDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwMgYIKwYBBQUHAQEEJjAk MCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC50aGF3dGUuY29tMA0GCSqGSIb3DQEB BQUAA4GBAF/BVQRh2QOAtH8491d2XIKqdRZNY4OUMh6qccb0xLGNTDx3E4iwoYHc yi2axElQG+7VAEIbDftzfhVUttsPwLI0BM2Nvz6KkwnlrJmt9HuZOjyv9M6szCxX jHqVXkTDtrvRzT3hHTLD63l4PAqAUDpR4Th4N23IyxpgVqmYZwoJ -END CERTIFICATE- into a file pop.gmx.net.pem and copied ths file into /etc/fetchmail/certs Than I downloaded the whole package of root certificates from here https://www.verisign.com/support/thawte-roots.zip unpacked it and copied each *.pem file into /etc/fetchmail/certs also. I renamend the files to not to contain blanks with detox. Then I run as root the command $ c_rehash /etc/fetchmail/certs I checked /etc/fetchmail/certs and found all files being symlinked to something which looks like hash keys (?). c_hash does not submit any error message. After this I added below the poll section of my accounts $HOME/.fetchmailrc the following line: sslcertpath /etc/fetchmail/certs Nonetheless fetchmail complains about local certifcates. What do I have to do to fix this ? Best regards and thank you for any help in advance! mcc Sendmail and I think fetchmail (haven't used the latter yet) do a strict check of certs against a local store. The error above tells you to add to your .fetchmailrc the option of sslcertck. Did you do that? So your .fetchmailrc should show something like: user 'm...@gmx_whatever.com' with pass 123456 is 'mcc' here options ssl sslcertck sslcertpath '/etc/fetchmail/certs' If you have done the above and still does not work then the problem may be that the user you are running fetchmail as does not have read access to your /etc/fetchmail/certs. Change that to a ~/fetchmail/.certs and it should work. HTH. -- Regards, Mick Hi Mick, thank you for your help. :) I currently have this line in my fetchtmailrc (the rest is commented out). This had worked until the ssl/cert-showdown: poll pop.gmx.net protocol pop3 user meino.cra...@gmx.de password this is the password mda
Re: [gentoo-user] fetchmail + certs = problems
On Saturday 02 October 2010 15:17:01 meino.cra...@gmx.de wrote: Mick michaelkintz...@gmail.com [10-10-02 13:52]: On Saturday 02 October 2010 11:31:38 meino.cra...@gmx.de wrote: Hi, fetchmail's log told me, that there is something wrong with the setup of the certificats. In the log there is the following section fetchmail: Server certificate: fetchmail: Issuer Organization: Thawte Consulting cc fetchmail: Issuer CommonName: Thawte Premium Server CA fetchmail: Subject CommonName: pop.gmx.net fetchmail: pop.gmx.net key fingerprint: A6:57:BC:4A:97:AD:DB:99:00:E9:3A:B8:81:55:D7:B6 fetchmail: Server certificate verification error: unable to get local issuer certificate fetchmail: This means that the root signing certificate (issued for /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=pop.gmx.net) is not in the trusted CA certificate locations, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page. fetchmail: Server certificate: fetchmail: Issuer Organization: Thawte Consulting cc fetchmail: Issuer CommonName: Thawte Premium Server CA fetchmail: Subject CommonName: pop.gmx.net fetchmail: Server certificate verification error: certificate not trusted fetchmail: Server certificate: fetchmail: Issuer Organization: Thawte Consulting cc fetchmail: Issuer CommonName: Thawte Premium Server CA fetchmail: Subject CommonName: pop.gmx.net fetchmail: Server certificate verification error: unable to verify the first certificate fetchmail: Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!) In beforehand I did the following: From the output of this command # openssl s_client -connect pop.gmx.net:995 -showcerts I copied the section -BEGIN CERTIFICATE- MIIDUzCCArygAwIBAgIQDNZUbIDJ5EM+DVSd5AzXOjANBgkqhkiG9w0BAQUFADCB zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl cnZlckB0aGF3dGUuY29tMB4XDTEwMDQyMjAwMDAwMFoXDTEzMDUwOTIzNTk1OVow WDELMAkGA1UEBhMCREUxDzANBgNVBAgTBkJheWVybjEPMA0GA1UEBxQGTXVuaWNo MREwDwYDVQQKFAhHTVggR21iSDEUMBIGA1UEAxQLcG9wLmdteC5uZXQwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMu3VYZP3YqpNweeIp+zIYtAlYL9Nya5hq6j k+ShUtukV1746nqJto70+4oNhCYJ33mMw+vS5fODjuggG+Z1xcL5YU8mUyG2E7fH YkfNtHHMhRntN15ml7Kv3c52kmOI09r2psnlNPkkNx5shneON8jZfXYlqQq5Vq1l Hz+jEjFrAgMBAAGjgaYwgaMwDAYDVR0TAQH/BAIwADBABgNVHR8EOTA3MDWgM6Ax hi9odHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlU2VydmVyUHJlbWl1bUNBLmNy bDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwMgYIKwYBBQUHAQEEJjAk MCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC50aGF3dGUuY29tMA0GCSqGSIb3DQEB BQUAA4GBAF/BVQRh2QOAtH8491d2XIKqdRZNY4OUMh6qccb0xLGNTDx3E4iwoYHc yi2axElQG+7VAEIbDftzfhVUttsPwLI0BM2Nvz6KkwnlrJmt9HuZOjyv9M6szCxX jHqVXkTDtrvRzT3hHTLD63l4PAqAUDpR4Th4N23IyxpgVqmYZwoJ -END CERTIFICATE- into a file pop.gmx.net.pem and copied ths file into /etc/fetchmail/certs Than I downloaded the whole package of root certificates from here https://www.verisign.com/support/thawte-roots.zip unpacked it and copied each *.pem file into /etc/fetchmail/certs also. I renamend the files to not to contain blanks with detox. Then I run as root the command $ c_rehash /etc/fetchmail/certs I checked /etc/fetchmail/certs and found all files being symlinked to something which looks like hash keys (?). c_hash does not submit any error message. After this I added below the poll section of my accounts $HOME/.fetchmailrc the following line: sslcertpath /etc/fetchmail/certs Nonetheless fetchmail complains about local certifcates. What do I have to do to fix this ? Best regards and thank you for any help in advance! mcc Sendmail and I think fetchmail (haven't used the latter yet) do a strict check of certs against a local store. The error above tells you to add to your .fetchmailrc the option of sslcertck. Did you do that? So your .fetchmailrc should show something like: user 'm...@gmx_whatever.com' with pass 123456 is 'mcc' here options ssl sslcertck sslcertpath '/etc/fetchmail/certs' If you have done the above and still does not work then the problem may be that the user you are running fetchmail as does not have read access to your /etc/fetchmail/certs. Change that to a ~/fetchmail/.certs and it should work. HTH. Hi Mick, thank you for your help. :) I currently have this line in my fetchtmailrc
Re: [gentoo-user] Fetchmail
Hi, I run fetchmail to poll 3 servers every minute... and while this has worked fine for weeks, last night it froze at 2am and stopped polling. When I killed the fetchmail process and ran fetchmail again this afternoon, things jumped to life again and appear back to normal... but I wished I didn't have to make the manual intervention. Fetchmail is version 6.2.5.2+RPA+NTLM+SDPS+SSL+INET6+NLS from portage and has the following in ~/.fetchmailrc [...] -- Can anyone tell me why this happened? Hard to say. There's no evidence in the cited log. I think you may want to increase verbosity of the logs... Hm, and next time don't just kill the running instance but check what it's actually doing using strace and ltrace (or even a debugger, but this won't help much if debug symbols are stripped...). You've compiled in a lot of auth mechs, so it may well be due to a related library (hence I suggested ltrace, too). -hwh -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] fetchmail+procmail+mutt and gentoo maillists
It seems as though one extremely large mail is causing you to run into bug 85339. Solution: use getmail instead :) Regards, Tom -- Tom Martin, http://dev.gentoo.org/~slarti AMD64, net-mail, shell-tools, recruiters, vim Gentoo Linux pgpKODneiO7pk.pgp Description: PGP signature
