«

In message <h91g2d$mdj$>, Lawrence D'Oliveiro wrote:

> There's no explicit option in fetchmail to turn this off, but if I tell it
> to use SSL specifically, this causes it to skip the TLS negotiation and I
> don't get the certificate expiry warning any more.

Nope, this doesn't work. So now I'm doing

fetchmail -sf ~/etc/fetchmailrc 2>&1 | grep -v "certificate has expired"

to ignore the warning.

On Sun, 20 Sep 2009 12:15:22 +1200, Lawrence D'Oliveiro
<_zealand> wrote:

>In message <>, Carnations wrote:
>
>> And yes - I agree - confidential emails should be encrypted from source -
>> as should their replies.
>
>Which would be better--public-key or secret-key encryption?

Public key is much easier, as you do not have to have some secret way
of sending a key. AFAIK, they are both equally good encryptions.

On Sun, 20 Sep 2009 12:29:48 +1200, Lawrence D'Oliveiro
<_zealand> wrote:

>In message <h91g2d$mdj$>, Lawrence D'Oliveiro wrote:
>
>> There's no explicit option in fetchmail to turn this off, but if I tell it
>> to use SSL specifically, this causes it to skip the TLS negotiation and I
>> don't get the certificate expiry warning any more.
>
>Nope, this doesn't work. So now I'm doing
>
> fetchmail -sf ~/etc/fetchmailrc 2>&1 | grep -v "certificate has expired"
>
>to ignore the warning.

Maybe you should get the source and do a patch to add an option, then
send it back to the developers.

In message <>, Stephen Worthington
wrote:

> On Sun, 20 Sep 2009 12:15:22 +1200, Lawrence D'Oliveiro
> <_zealand> wrote:
>
>>In message <>, Carnations wrote:
>>
>>> And yes - I agree - confidential emails should be encrypted from source
>>> - as should their replies.
>>
>>Which would be better--public-key or secret-key encryption?
>
> Public key is much easier, as you do not have to have some secret way
> of sending a key.

But you still have the problem of trusting the public key.

> AFAIK, they are both equally good encryptions.

It's not either/or.

In message <>, Stephen Worthington
wrote:

> Maybe you should get the source and do a patch to add an option, then
> send it back to the developers.

Yeah, I thought about that. But it turns out this is a known issue. From the
FAQ:

Some servers advertise STLS (POP3) or STARTTLS (IMAP), and fetchmail
will automatically attempt TLS negotiation if SSL was enabled at
compile time. This can however cause problems if the upstream didn't
configure his certificates properly.

In order to prevent fetchmail from trying TLS (STLS, STARTTLS)
negotiation, add this option:

sslproto ssl23

This restricts fetchmail's SSL/TLS protocol choice from the default
"SSLv2, SSLv3, TLSv1" to the two SSL variants, disabling TLSv1. Note
however that this causes the connection to be unencrypted unless an
encrypting "plugin" is used or SSL is requested explicitly.

And yes, that does work.

On Sun, 20 Sep 2009 14:17:44 +1200, Lawrence D'Oliveiro
<_zealand> wrote:

>In message <>, Stephen Worthington
>wrote:
>
>> On Sun, 20 Sep 2009 12:15:22 +1200, Lawrence D'Oliveiro
>> <_zealand> wrote:
>>
>>>In message <>, Carnations wrote:
>>>
>>>> And yes - I agree - confidential emails should be encrypted from source
>>>> - as should their replies.
>>>
>>>Which would be better--public-key or secret-key encryption?
>>
>> Public key is much easier, as you do not have to have some secret way
>> of sending a key.
>
>But you still have the problem of trusting the public key.

In the same way that you have a problem trusting a private key that is
sent to you somehow. Only it is much easier to get the key. You can
freely publish your public key on your web page with no loss of
security. If the person you want to email is the owner of that web
page and that is the only way you know him, then you can trust his
public key from there as much as any other way he might get you a key
(unless his web server has been hacked). There is always a problem
trusting the initial setup of secure communications. At some point,
you just have to decide to trust something and go ahead and see how it
works out.

>> AFAIK, they are both equally good encryptions.
>
>It's not either/or.

Well, yes, you could use both at once if you are paranoid.

In message <>, Stephen Worthington
wrote:

> On Sun, 20 Sep 2009 14:17:44 +1200, Lawrence D'Oliveiro
> <_zealand> wrote:
>
>>But you still have the problem of trusting the public key.
>
> In the same way that you have a problem trusting a private key that is
> sent to you somehow.

Private keys must NEVER be disclosed.

On Sun, 20 Sep 2009 12:15:22 +1200, Lawrence D'Oliveiro wrote:

> In message <>, Carnations wrote:
>
>> And yes - I agree - confidential emails should be encrypted from source
>> - as should their replies.
>
> Which would be better--public-key or secret-key encryption?

Surely you should use encryption that *only* the recipient can decipher.

How you chose to do that is the concern only of the two of you.

If you make a "public" key available either to everyone, or to one person only (using whatever delivery
method you chose) that requires your undisclosed private key in order to decrypt the text, then only you
will be able to read the encoded message.

....And the longer the key the better.


--
"Filtering the Internet is like trying to boil the ocean"

In message <>, Carnations wrote:

> On Sun, 20 Sep 2009 12:15:22 +1200, Lawrence D'Oliveiro wrote:
>
>> In message <>, Carnations wrote:
>>
>>> And yes - I agree - confidential emails should be encrypted from source
>>> - as should their replies.
>>
>> Which would be better--public-key or secret-key encryption?
>
> Surely you should use encryption that *only* the recipient can decipher.

Not necessarily. Digital signatures can be decrypted by anybody.

> If you make a "public" key available either to everyone ...

But a public key still has to be distributed in a trusted fashion.

On Sun, 20 Sep 2009 22:41:11 +1200, Lawrence D'Oliveiro wrote:

>> If you make a "public" key available either to everyone ...
>
> But a public key still has to be distributed in a trusted fashion.

The whole point of the "public" key is that it is available to all and sundry for use by all and sundry for
sending a message exclusively to you in a way that nobody else can read without spending a very
substantial quantity of resources to break your private key - certainly not easily read.


--
"Filtering the Internet is like trying to boil the ocean"