* [gentoo-user] fetchmail + certs = problems
@ 2010-10-02 10:31 meino.cramer
2010-10-02 11:47 ` Mick
2010-10-03 19:57 ` Heiko Zinke
0 siblings, 2 replies; 6+ messages in thread
From: meino.cramer @ 2010-10-02 10:31 UTC (permalink / raw
To: Gentoo
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-user] fetchmail + certs = problems
2010-10-02 10:31 [gentoo-user] fetchmail + certs = problems meino.cramer
@ 2010-10-02 11:47 ` Mick
2010-10-02 14:17 ` meino.cramer
2010-10-03 19:57 ` Heiko Zinke
1 sibling, 1 reply; 6+ messages in thread
From: Mick @ 2010-10-02 11:47 UTC (permalink / raw
To: gentoo-user
[-- Attachment #1: Type: Text/Plain, Size: 4768 bytes --]
On Saturday 02 October 2010 11:31:38 meino.cramer@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 'mcc@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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-user] fetchmail + certs = problems
2010-10-02 11:47 ` Mick
@ 2010-10-02 14:17 ` meino.cramer
2010-10-02 16:30 ` Mick
0 siblings, 1 reply; 6+ messages in thread
From: meino.cramer @ 2010-10-02 14:17 UTC (permalink / raw
To: gentoo-user
Mick <michaelkintzios@gmail.com> [10-10-02 13:52]:
> On Saturday 02 October 2010 11:31:38 meino.cramer@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 'mcc@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.Cramer@gmx.de" password "<this is the password>" mda "/usr/bin/procmail -d %T"
In the inet and in your post I found a totally different syntax...so
it seems that I have lived behind the moon for a long time I didn't
get all the new syntax changes according to fetchmail ;)
I chenged the above line to
poll pop.gmx.net protocol pop3 user "Meino.Cramer@gmx.de" password "<this is the password>" mda "/usr/bin/procmail -d %T" options ssl
sslcertck sslcertpath '/etc/fetchmail/certs'
which results with
fetchmail -v
in
fetchmail: 6.3.17 querying pop.gmx.net (protocol POP3) at Sat Oct 2 16:12:51 2010: poll started
Trying to connect to 212.227.17.185/995...connected.
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.
17550:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:982:
fetchmail: SSL connection failed.
fetchmail: socket error while fetching from Meino.Cramer@gmx.de@pop.gmx.net
fetchmail: 6.3.17 querying pop.gmx.net (protocol POP3) at Sat Oct 2 16:12:51 2010: poll completed
fetchmail: Query status=2 (SOCKET)
fetchmail: normal termination, status 2
ls -l /etc/fetchmail/certs:
total 44
lrwxrwxrwx 1 root root 30 Oct 2 12:10 09ca81a7.0 -> Thawte_Personal_Premium_CA.pem
lrwxrwxrwx 1 root root 26 Oct 2 12:10 2e4eed3c.0 -> thawte_Primary_Root_CA.pem
lrwxrwxrwx 1 root root 28 Oct 2 12:10 3a7f6b22.0 -> Thawte_Personal_Basic_CA.pem
lrwxrwxrwx 1 root root 50 Oct 2 12:10 415660c1.0 -> Class_3_Public_Primary_Certification_Authority.pem
lrwxrwxrwx 1 root root 31 Oct 2 12:10 64d1f6f4.0 -> Thawte_Personal_Freemail_CA.pem
lrwxrwxrwx 1 root root 31 Oct 2 12:10 64d1f6f4.1 -> thawte_Personal_Freemail_CA.pem
lrwxrwxrwx 1 root root 20 Oct 2 12:10 6cc3c4c3.0 -> Thawte_Server_CA.pem
lrwxrwxrwx 1 root root 28 Oct 2 12:10 98ec67f0.0 -> Thawte_Premium_Server_CA.pem
lrwxrwxrwx 1 root root 26 Oct 2 12:10 9e6afd31.0 -> Thawte_Timestamping_CA.pem
-rw-r--r-- 1 root root 833 Oct 2 12:06 Class_3_Public_Primary_Certification_Authority.pem
-rw-r--r-- 1 root root 1167 Oct 2 12:06 Thawte_Personal_Basic_CA.pem
-rw-r--r-- 1 root root 1183 Oct 2 12:06 Thawte_Personal_Freemail_CA.pem
-rw-r--r-- 1 root root 1175 Oct 2 12:06 Thawte_Personal_Premium_CA.pem
-rw-r--r-- 1 root root 1175 Oct 2 12:06 Thawte_Premium_Server_CA.pem
-rw-r--r-- 1 root root 1146 Oct 2 12:06 Thawte_Server_CA.pem
-rw-r--r-- 1 root root 992 Oct 2 12:06 Thawte_Timestamping_CA.pem
lrwxrwxrwx 1 root root 33 Oct 2 12:10 c089bbbd.0 -> thawte_Primary_Root_CA-G2_ECC.pem
lrwxrwxrwx 1 root root 15 Oct 2 12:10 ec4e2774.0 -> pop.gmx.net.pem
-rw-r--r-- 1 root root 1213 Oct 2 12:10 pop.gmx.net.pem
-rw-r--r-- 1 root root 1164 Oct 2 12:06 thawte_Personal_Freemail_CA.pem
-rw-r--r-- 1 root root 939 Oct 2 12:06 thawte_Primary_Root_CA-G2_ECC.pem
-rw-r--r-- 1 root root 1493 Oct 2 12:06 thawte_Primary_Root_CA.pem
everything is world readable...
Finally I did a fetchmail --version which gave me:
This is fetchmail release 6.3.17+RPA+NTLM+SDPS+SSL+NLS.
Copyright (C) 2002, 2003 Eric S. Raymond
Copyright (C) 2004 Matthias Andree, Eric S. Raymond,
Robert M. Funk, Graham Wilson
Copyright (C) 2005 - 2006, 2010 Sunil Shetye
Copyright (C) 2005 - 2010 Matthias Andree
Fetchmail comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. For details,
please see the file COPYING in the source or documentation directory.
Fallback MDA: (none)
Linux solfire 2.6.35.7 #2 SMP PREEMPT Thu Sep 30 14:29:29 CEST 2010 x86_64 AMD Phenom(tm) II X6 1090T Processor AuthenticAMD GNU/Linux
Taking options from command line and /home/mccramer/.fetchmailrc
Idfile is /home/mccramer/.fetchids
Fetchmail will forward misaddressed multidrop messages to mccramer.
Options for retrieving from Meino.Cramer@gmx.de@pop.gmx.net:
True name of server is pop.gmx.net.
Protocol is POP3.
All available authentication methods will be tried.
SSL encrypted sessions enabled.
SSL server certificate checking enabled.
SSL trusted certificate directory: /etc/fetchmail/certs
Server nonresponse timeout is 300 seconds (default).
Default mailbox selected.
Only new messages will be retrieved (--all off).
Fetched messages will not be kept on the server (--keep off).
Old messages will not be flushed before message retrieval (--flush off).
Oversized messages will not be flushed before message retrieval (--limitflush off).
Rewrite of server-local addresses is enabled (--norewrite off).
Carriage-return stripping is enabled (stripcr on).
Carriage-return forcing is disabled (forcecr off).
Interpretation of Content-Transfer-Encoding is enabled (pass8bits off).
MIME decoding is disabled (mimedecode off).
Idle after poll is disabled (idle off).
Nonempty Status lines will be kept (dropstatus off)
Delivered-To lines will be kept (dropdelivered off)
Fetch message size limit is 100 (--fetchsizelimit 100).
Do binary search of UIDs during 3 out of 4 polls (--fastuidl 4).
Messages will be delivered with "/usr/bin/procmail -d %T".
Single-drop mode: 1 local name recognized.
No UIDs saved from this host.
I have no clue, whether the certs are not accepted...
What did I wrong?
Best regards
mcc
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-user] fetchmail + certs = problems
2010-10-02 14:17 ` meino.cramer
@ 2010-10-02 16:30 ` Mick
0 siblings, 0 replies; 6+ messages in thread
From: Mick @ 2010-10-02 16:30 UTC (permalink / raw
To: gentoo-user
[-- Attachment #1: Type: Text/Plain, Size: 12818 bytes --]
On Saturday 02 October 2010 15:17:01 meino.cramer@gmx.de wrote:
> Mick <michaelkintzios@gmail.com> [10-10-02 13:52]:
> > On Saturday 02 October 2010 11:31:38 meino.cramer@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 'mcc@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 (the rest is commented out).
> This had worked until the ssl/cert-showdown:
>
> poll pop.gmx.net protocol pop3 user "Meino.Cramer@gmx.de" password
> "<this is the password>" mda "/usr/bin/procmail -d %T"
>
> In the inet and in your post I found a totally different syntax...so
> it seems that I have lived behind the moon for a long time I didn't
> get all the new syntax changes according to fetchmail ;)
>
> I chenged the above line to
> poll pop.gmx.net protocol pop3 user "Meino.Cramer@gmx.de" password
> "<this is the password>" mda "/usr/bin/procmail -d %T" options ssl
> sslcertck sslcertpath '/etc/fetchmail/certs'
>
> which results with
> fetchmail -v
> in
> fetchmail: 6.3.17 querying pop.gmx.net (protocol POP3) at Sat Oct 2
> 16:12:51 2010: poll started Trying to connect to
> 212.227.17.185/995...connected.
> 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.
> 17550:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
> verify failed:s3_clnt.c:982: fetchmail: SSL connection failed.
> fetchmail: socket error while fetching from
> Meino.Cramer@gmx.de@pop.gmx.net fetchmail: 6.3.17 querying pop.gmx.net
> (protocol POP3) at Sat Oct 2 16:12:51 2010: poll completed fetchmail:
> Query status=2 (SOCKET)
> fetchmail: normal termination, status 2
>
> ls -l /etc/fetchmail/certs:
> total 44
> lrwxrwxrwx 1 root root 30 Oct 2 12:10 09ca81a7.0 ->
> Thawte_Personal_Premium_CA.pem lrwxrwxrwx 1 root root 26 Oct 2 12:10
> 2e4eed3c.0 -> thawte_Primary_Root_CA.pem lrwxrwxrwx 1 root root 28 Oct
> 2 12:10 3a7f6b22.0 -> Thawte_Personal_Basic_CA.pem lrwxrwxrwx 1 root root
> 50 Oct 2 12:10 415660c1.0 ->
> Class_3_Public_Primary_Certification_Authority.pem lrwxrwxrwx 1 root root
> 31 Oct 2 12:10 64d1f6f4.0 -> Thawte_Personal_Freemail_CA.pem lrwxrwxrwx
> 1 root root 31 Oct 2 12:10 64d1f6f4.1 ->
> thawte_Personal_Freemail_CA.pem lrwxrwxrwx 1 root root 20 Oct 2 12:10
> 6cc3c4c3.0 -> Thawte_Server_CA.pem lrwxrwxrwx 1 root root 28 Oct 2
> 12:10 98ec67f0.0 -> Thawte_Premium_Server_CA.pem lrwxrwxrwx 1 root root
> 26 Oct 2 12:10 9e6afd31.0 -> Thawte_Timestamping_CA.pem -rw-r--r-- 1 root
> root 833 Oct 2 12:06 Class_3_Public_Primary_Certification_Authority.pem
> -rw-r--r-- 1 root root 1167 Oct 2 12:06 Thawte_Personal_Basic_CA.pem
> -rw-r--r-- 1 root root 1183 Oct 2 12:06 Thawte_Personal_Freemail_CA.pem
> -rw-r--r-- 1 root root 1175 Oct 2 12:06 Thawte_Personal_Premium_CA.pem
> -rw-r--r-- 1 root root 1175 Oct 2 12:06 Thawte_Premium_Server_CA.pem
> -rw-r--r-- 1 root root 1146 Oct 2 12:06 Thawte_Server_CA.pem
> -rw-r--r-- 1 root root 992 Oct 2 12:06 Thawte_Timestamping_CA.pem
> lrwxrwxrwx 1 root root 33 Oct 2 12:10 c089bbbd.0 ->
> thawte_Primary_Root_CA-G2_ECC.pem lrwxrwxrwx 1 root root 15 Oct 2 12:10
> ec4e2774.0 -> pop.gmx.net.pem -rw-r--r-- 1 root root 1213 Oct 2 12:10
> pop.gmx.net.pem
> -rw-r--r-- 1 root root 1164 Oct 2 12:06
> thawte_Personal_Freemail_CA.pem -rw-r--r-- 1 root root 939 Oct 2 12:06
> thawte_Primary_Root_CA-G2_ECC.pem -rw-r--r-- 1 root root 1493 Oct 2 12:06
> thawte_Primary_Root_CA.pem
>
> everything is world readable...
>
> Finally I did a fetchmail --version which gave me:
> This is fetchmail release 6.3.17+RPA+NTLM+SDPS+SSL+NLS.
>
> Copyright (C) 2002, 2003 Eric S. Raymond
> Copyright (C) 2004 Matthias Andree, Eric S. Raymond,
> Robert M. Funk, Graham Wilson
> Copyright (C) 2005 - 2006, 2010 Sunil Shetye
> Copyright (C) 2005 - 2010 Matthias Andree
> Fetchmail comes with ABSOLUTELY NO WARRANTY. This is free software, and
> you are welcome to redistribute it under certain conditions. For details,
> please see the file COPYING in the source or documentation directory.
>
> Fallback MDA: (none)
> Linux solfire 2.6.35.7 #2 SMP PREEMPT Thu Sep 30 14:29:29 CEST 2010
> x86_64 AMD Phenom(tm) II X6 1090T Processor AuthenticAMD GNU/Linux Taking
> options from command line and /home/mccramer/.fetchmailrc Idfile is
> /home/mccramer/.fetchids
> Fetchmail will forward misaddressed multidrop messages to mccramer.
> Options for retrieving from Meino.Cramer@gmx.de@pop.gmx.net:
> True name of server is pop.gmx.net.
> Protocol is POP3.
> All available authentication methods will be tried.
> SSL encrypted sessions enabled.
> SSL server certificate checking enabled.
> SSL trusted certificate directory: /etc/fetchmail/certs
> Server nonresponse timeout is 300 seconds (default).
> Default mailbox selected.
> Only new messages will be retrieved (--all off).
> Fetched messages will not be kept on the server (--keep off).
> Old messages will not be flushed before message retrieval (--flush
> off). Oversized messages will not be flushed before message retrieval
> (--limitflush off). Rewrite of server-local addresses is enabled
> (--norewrite off). Carriage-return stripping is enabled (stripcr on).
> Carriage-return forcing is disabled (forcecr off).
> Interpretation of Content-Transfer-Encoding is enabled (pass8bits
> off). MIME decoding is disabled (mimedecode off).
> Idle after poll is disabled (idle off).
> Nonempty Status lines will be kept (dropstatus off)
> Delivered-To lines will be kept (dropdelivered off)
> Fetch message size limit is 100 (--fetchsizelimit 100).
> Do binary search of UIDs during 3 out of 4 polls (--fastuidl 4).
> Messages will be delivered with "/usr/bin/procmail -d %T".
> Single-drop mode: 1 local name recognized.
> No UIDs saved from this host.
>
> I have no clue, whether the certs are not accepted...
>
> What did I wrong?
>
> Best regards
> mcc
Hmm ... can't see anything amiss, but as I said I have not used fetchmail.
Perhaps a more seasoned fetchmail gentooist will chime in here.
Until then three more things to check, or do:
Have you installed *all* the CA root certs?
(There may be some intermediate certs that are required - you will need the
complete chain of the root certs saved in your /etc/fetchmail/certs and then
run c_rehash. Check the atime of the contents of your /etc/fetchmail/certs to
make sure that the c_rehash worked).
Also add:
sslfingerprint A6:57:BC:4A:97:AD:DB:99:00:E9:3A:B8:81:55:D7:B6
to your fetchtmailrc.
Finally, just in case the access rights are somewhat incorrect, copy your
/etc/fetchmail/certs to ~/.fetchmail/.certs and run c_rehash for that
directory.
HTH.
--
Regards,
Mick
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-user] fetchmail + certs = problems
2010-10-02 10:31 [gentoo-user] fetchmail + certs = problems meino.cramer
2010-10-02 11:47 ` Mick
@ 2010-10-03 19:57 ` Heiko Zinke
2010-10-04 0:31 ` meino.cramer
1 sibling, 1 reply; 6+ messages in thread
From: Heiko Zinke @ 2010-10-03 19:57 UTC (permalink / raw
To: gentoo-user
[-- Attachment #1: Type: text/plain, Size: 3512 bytes --]
On Sat, Oct 02, 2010 at 12:31:38PM +0200, meino.cramer@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:
heiko@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.
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-user] fetchmail + certs = problems
2010-10-03 19:57 ` Heiko Zinke
@ 2010-10-04 0:31 ` meino.cramer
0 siblings, 0 replies; 6+ messages in thread
From: meino.cramer @ 2010-10-04 0:31 UTC (permalink / raw
To: gentoo-user
Heiko Zinke <mails@rabuju.com> [10-10-03 22:01]:
> On Sat, Oct 02, 2010 at 12:31:38PM +0200, meino.cramer@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:
> heiko@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-10-04 1:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-02 10:31 [gentoo-user] fetchmail + certs = problems meino.cramer
2010-10-02 11:47 ` Mick
2010-10-02 14:17 ` meino.cramer
2010-10-02 16:30 ` Mick
2010-10-03 19:57 ` Heiko Zinke
2010-10-04 0:31 ` meino.cramer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox