Re: [gentoo-user] fetchmail + certs = problems

2010-10-03 Thread meino . cramer 

Heiko Zinke  [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

2010-10-03 Thread Heiko Zinke 
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

2010-10-02 Thread Mick 
On Saturday 02 October 2010 15:17:01 meino.cra...@gmx.de wrote:
> Mick  [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

Re: [gentoo-user] fetchmail + certs = problems

2010-10-02 Thread meino . cramer 
Mick  [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

Re: [gentoo-user] fetchmail + certs = problems

2010-10-02 Thread Mick 
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.

[gentoo-user] fetchmail + certs = problems

2010-10-02 Thread meino . cramer 
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

Re: [gentoo-user] Fetchmail

2005-12-13 Thread Hans-Werner Hilse 
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

[gentoo-user] Fetchmail

2005-12-13 Thread Steve [Gentoo] 
I've recently experienced a bizarre failure... and I wondered if anyone 
else has experienced something similar or has a suggestion to avoid a 
similar annoyance in future.


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


--
set postmaster "[EMAIL PROTECTED]"
set no bouncemail
set no spambounce
set logfile .fetchmail.log
set properties ""
set daemon 60
poll pop3.host1.net with proto POP3
   user 'user1' there with password 'pass1' is 'me' here options 
stripcr

poll pop3.host1.net with proto POP3
   user 'user2' there with password 'pass2' is 'me' here options 
stripcr

poll mail.host2.org with proto POP3
   user 'user3' there with password 'pass3' is 'me' here with 
options stripcr

--
The tail of the trace file read:
--
fetchmail: awakened at Tue Dec 13 01:59:58 2005
fetchmail: 1 message for user2 at pop3.host1.net (5449 octets).
fetchmail: reading message [EMAIL PROTECTED]:1 of 1 (5449 octets) 
fetchmail:  flushed

fetchmail: sleeping at Tue Dec 13 02:00:12 2005
fetchmail: awakened at Tue Dec 13 02:01:12 2005
fetchmail: 2 messages for user2 at pop3.host1.net (11540 octets).
fetchmail: reading message [EMAIL PROTECTED]:1 of 2 (5020 octets) 
fetchmail:  flushed
fetchmail: reading message [EMAIL PROTECTED]:2 of 2 (6520 octets) 
fetchmail:  flushed

--
Can anyone tell me why this happened?

--
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] fetchmail+procmail+mutt and gentoo maillists

2005-04-30 Thread slarti 
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

[gentoo-user] fetchmail+procmail+mutt and gentoo maillists

2005-04-30 Thread Pavel 
Hello,

I`ve subscribed to gentoo mailists , but can only read through Gmail Web Interface .
I followed Offical Gentoo Mail guide , but no luck 

Here is my .fetchmailrc 

set logfile /var/log/fetchmail
poll pop.gmail.com  proto pop3 port 995 
user xxx with pass xxx to pavel here
ssl

When I try to fetch mail I get this error 
 
[ ~ ] pavel $ fetchmail -akv -m "/usr/bin/procmail -d %T" 
fetchmail: 6.2.5 querying pop.gmail.com (protocol POP3) : poll started
fetchmail: Issuer Organization: Thawte Consulting cc
fetchmail: Issuer CommonName: Thawte Server CA
fetchmail: Server CommonName: pop.gmail.com
fetchmail: pop.gmail.com key fingerprint: F2:BE:86:E4:E2:51:76:AA:B6:00:91:7B:97:A4:E6:F3
fetchmail: Warning: server certificate verification: unable to get local issuer certificate
fetchmail: Issuer Organization: Thawte Consulting cc
fetchmail: Issuer CommonName: Thawte Server CA
fetchmail: Server CommonName: pop.gmail.com
fetchmail: Warning: server certificate verification: certificate not trusted
fetchmail: Issuer Organization: Thawte Consulting cc
fetchmail: Issuer CommonName: Thawte Server CA
fetchmail: Server CommonName: pop.gmail.com
fetchmail: Warning: server certificate verification: unable to verify the first certificate
fetchmail: POP3< +OK Gpop ready.
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< USER
fetchmail: POP3< RESP-CODES
fetchmail: POP3< EXPIRE 0
fetchmail: POP3< LOGIN-DELAY 300
fetchmail: POP3< X-GOOGLE-VERHOEVEN
fetchmail: POP3< .
fetchmail: POP3> USER plhvnx
fetchmail: POP3< +OK send PASS
fetchmail: POP3> PASS *
fetchmail: POP3< +OK Welcome.
fetchmail: POP3> STAT
fetchmail: POP3< +OK 766 11880767
fetchmail: 766 messages for plhvnx at pop.gmail.com (11880767 octets).
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 1913
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK message follows
fetchmail: reading message [EMAIL PROTECTED]:1 of 766 (1913 octets)
#.**fetchmail:  not flushed
fetchmail: POP3> LIST 2
fetchmail: POP3< +OK 2 1901
fetchmail: POP3> RETR 2
fetchmail: POP3< +OK message follows
fetchmail: reading message [EMAIL PROTECTED]:2 of 766 (1901 octets)
#.**fetchmail:  not flushed
fetchmail: POP3> LIST 3
fetchmail: POP3< +OK 3 1923
fetchmail: POP3> RETR 3
fetchmail: POP3< +OK message follows
fetchmail: reading message [EMAIL PROTECTED]:3 of 766 (1923 octets)
#.**fetchmail:  not flushed
fetchmail: POP3> LIST 4
fetchmail: POP3< +OK 4 1902
fetchmail: POP3> RETR 4
fetchmail: POP3< +OK message follows
fetchmail: reading message [EMAIL PROTECTED]:4 of 766 (1902 octets)
#.**fetchmail:  not flushed
fetchmail: POP3> LIST 5
fetchmail: POP3< +OK 5 740
fetchmail: POP3> RETR 5
fetchmail: POP3< +OK message follows
fetchmail: reading message [EMAIL PROTECTED]:5 of 766 (740 octets)
#**fetchmail:  not flushed
fetchmail: POP3> LIST 6
fetchmail: POP3< +OK 6 850
fetchmail: POP3> RETR 6
fetchmail: POP3< +OK message follows
fetchmail: reading message [EMAIL PROTECTED]:6 of 766 (850 octets)
#fetchmail:  not flushed
fetchmail: POP3> LIST 7
fetchmail: POP3< +OK 7 690
fetchmail: POP3> RETR 7
fetchmail: POP3< +OK message follows
fetchmail: reading message [EMAIL PROTECTED]:7 of 766 (690 octets)
#fetchmail:  not flushed
fetchmail: POP3> LIST 8
fetchmail: POP3< +OK 8 875
fetchmail: POP3> RETR 8
fetchmail: POP3< +OK message follows
fetchmail: reading message [EMAIL PROTECTED]:8 of 766 (875 octets)
#**fetchmail:  not flushed
fetchmail: POP3> LIST 9
fetchmail: POP3< +OK 9 429
fetchmail: POP3> RETR 9
fetchmail: POP3< +OK message follows
fetchmail: reading message [EMAIL PROTECTED]:9 of 766 (429 octets)
#*fetchmail:  not flushed
fetchmail: POP3> LIST 10
fetchmail: POP3< +OK 10 3699
fetchmail: POP3> RETR 10
fetchmail: POP3< +OK message follows
fetchmail: reading message [EMAIL PROTECTED]:10 of 766 (3699 octets)
#.**.***fetchmail:  not flushed
fetchmail: POP3> LIST 11
fetchmail: POP3< +OK 11 3818
fetchmail: POP3> RETR 11
fetchmail: POP3< +OK message follows
fetchmail: reading message [EMAIL PROTECTED]:11 of 766 (3818 octets)
#.**.***fetchmail:  not flushed
fetchmail: POP3> LIST 12
fetchmail: POP3< +OK 12 6053451
fetchmail: POP3> RETR 12
fetchmail: POP3< +OK message follows
fetchmail: reading message [EMAIL PROTECTED]:12 of 766 (6053451 octets)
#*.*.*.*.*.*.*.*.**.*.*.*.*.*.*.*.**.*.*.*.*.*.*.*.**.*.*.*.*.*.*.**.*.*.*.*