> fetchmail: Server CommonName mismatch: localhost.localdomain != inmail.njm.f2s.com
> fetchmail: Server certificate verification error: self signed certificate
> So it looks like fetchmail is complaining about my ISPs setup. Is that
> right?
Yes. Your ISP is using a self-baked certificate; it's cheap (i.e. free).
On the negative, your fetchmail (and browser, etc) have no idea whether
your ISP is trustworthy, or is in fact the person/entity it claims to
be. To teach fetchmail about both, you need to load your ISP's CA
(certificate authority) into your openssh setup. By doing so, you
personally assume liability for aforementioned claims to be true.
The use of certificates here is to increase security. Security here
means:
1) Each time you run fetchmail, the connection which is opened is
guaranteed to be to <someone> at the other end. You expect that someone
to be your ISP.
2) The connection is encrypted, and protected from eavesdropping by
anyone other than a) yourself, b) that "someone".
The trick is to make sure that the "someone" is in fact your ISP. With
self-signed certificates, the only guaranteed way to do so is to jump
into your car and to pick up the CA from your ISP in person.
The shortcut is to read out your ISP's certificate fingerprint, and to
load this into fetchmail 6.3.4 or above. This solves your problem, but
you then have two possibilities when you've loaded the fingerprint:
1) You loaded the fingerprint of your ISP's CA into fetchmail. You have
security as good as it'll possibly get. Self-signed cert or otherwise.
2) You loaded the fingerprint of an imposter, assuming the imposter to
be your ISP. Both you and the imposter will read your email.
Your alternative is quite likely using plain text passwords. Even
possibility 2) is an improvement to that, because reading your email is
restricted from everyone, to you and the imposter.
Volker
--
Volker Kuhlmann is list0570 with the domain in header
http://volker.dnsalias.net/ Please do not CC list postings to me.
|
